[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]