InCommon metadata support

[Nick Roy <>]

On 25 Mar 2019, at 15:59, Cantor, Scott wrote:

> On 3/25/19, 5:36 PM, " on behalf of 
> Garmer, Jack - garmercj" < on behalf 
> of > wrote:
>
>> From what I understand, the DCV gives authorization to create certificates 
>> using our domain, which may be a decision
>> that is above my level.
>
> Permission to register metadata containing an entityID or endpoints in a 
> domain != permission to issue a certificate for a domain. Metadata is about 
> binding keys and endpoints, it has nothing to do with certificates and is 
> in fact a wholesale replacement for what they do in non-SAML trust models 
> like browsers talking to web servers.
>
> A certificate issuance grant is another use case for a domain 
> authorization, but that isn't necessary for anything to do with SAML 
> metadata.
>
>> My question is: is it common practice to authorize creation of 
>> certificates and metadata on behalf of an organization by
>> an outside vendor?
>
> Most vendors don't want anything to do with InCommon unless forced, so it's 
> certainly not common, but it does happen when necessary, and you're in a 
> gray area when you have something on your network that would be in your DNS 
> but somebody else is registering and managing. That's just InCommon's way 
> of allowing it with appropriate authorization from the domain owner.
>
> I've done at least one in recent memory.

Indeed, while it's odd that they would request to do DCV in order to register 
this SP on your behalf, it would effectively be one less SP you have to 
manage metadata for. It's certainly something people have done using our 
domain control process for the federation.

Nick

>
> -- Scott

Attachment: signature.asc
Description: OpenPGP digital signature