OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Service/ProviderID


On Dec 10, 2008, at 2:56 AM, Nat Sakimura wrote:

> <XRD>
>   <CanonicalID>https://example.com/server#14235435672</CanonicalID>
>   <Service>
>     <Type>http://specs.openid.net/auth/2.0/signon</Type>
>     <URI>https://example.com/server/signon</URI>
>   </Service>
> </XRD>
>
> When it does, it checks the CanonicalID to see this is the XRD of  
> the intended Service and then checks the  signature with the cert  
> that has this CanonicalID as the SubjectUniqueIdentifier. This way,  
> the RP finds out that this Authentication Provider IS the one that  
> was delegated by the user.


We need to be careful here that the resolution and trust models can be  
supported for service enumeration as well.  Consider the use case  
where an entity (https://calendar.example.biz/foo/bar) provides a set  
of calendar services, some of which may use providerID as a bootstrap  
into those other protocols (the XRI-SAML profiles do this for entityID  
for SAML metadata).

Do we need to trust the relationship between the service endpoint URI  
keys (TLS) and the XRD keys (DSIG)?  if so, i think we'll need to  
preserve providerID (or canonicalID) anyway.

I'd have to revisit the SAML work, to see if what your suggesting  
breaks assumptions made for those profiles.

=peterd



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]