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] XRD Signing (and SAML)



On Jun 22, 2009, at 5:09 PM, Will Norris wrote:

>
> On Jun 22, 2009, at 3:08 PM, Will Norris wrote:
>
>> ## My Proposed Action
>>
>> Unless someone points out something I'm overlooking, I'm fairly  
>> confident our current solution covers the use cases previously  
>> addressed with embedded SAML assertions.  I believe that this  
>> renders <TargetSubject /> and <TargetAuthority /> unnecessary.  I  
>> believe that most use cases involving the XRD chaining model of  
>> trust will only need a single <ds:KeyInfo /> (in fact that's all  
>> they've had to date).  For those use cases that need multiple  
>> <KeyInfo /> elements, I believe most will be limited to a period of  
>> time while transitioning off of a soon-to-be-expiring certificate.   
>> So I propose allowing for 0 or more <ds:KeyInfo /> elements  
>> underneath <Link /> (no wrapper element necessary), and doing away  
>> with the XRD Trust namespace and Target* elements.
>
> okay, hold off on the suggestion to remove <TargetAuthority />...  
> rethinking that.

nope, we're still good.  I was thinking about the use case where  
you're using PKI-based trust, but the subject of the certificate used  
to sign the XRD doesn't match anything anywhere in the document or in  
the URI used to retrieve the XRD.  For example (to borrow a little  
from Google's example):

% curl http://www.google.com/accounts/o8/xrd?uri=http%3A%2F%2Fmycompany.biz%2Fjoe

<XRD>
   <Subject>http://mycompany.biz/joe</Subject>
   <Alias>http://google.com/accounts/o8/xrd?uri=http%3A%2F%2Fmycompany.biz%2Fjoe 
</Alias>
   <ds:Signature>
     <ds:KeyName>hosted-id.google.com</ds:KeyName>
   </ds:Signature>
   <Link>
     <Rel>http://specs.openid.net/auth/2.0</Rel>
     <!-- ... -->
   </Link>
</XRD>

How else would an XRD consuming application know that "hosted- 
id.google.com" is a valid KeyName to use for signing this XRD unless  
the delegating XRD asserted that?  That was why we added  
TargetAuthority in the first place.

You do it the same way you would if you were doing the XRD-chaining  
model of trust, with <ds:KeyInfo />.  Only instead of embedding the  
entire certificate using <ds:X509Data />, you include the subject with  
<ds:KeyName />.  This is absolutely the right way to be doing this,  
rather than making up new elements like TargetAuthority.  So the  
delegating XRD would have:

<XRD>
   <Subject>http://mycompany.biz/joe</Subject>
   <ds:Signature>
     <ds:KeyName>mycompany.biz</ds:KeyName>
   </ds:Signature>
   <Link>
     <Rel>http://specs.openid.net/role/provider</Rel>
     <URI>http://google.com/accounts/o8/xrd?uri=http%3A%2F%2Fmycompany.biz%2Fjoe 
</URI>
     <ds:KeyInfo>
       <ds:KeyName>hosted-id.google.com</ds:KeyName>
     </ds:KeyInfo>
   </Link>
</XRD>

yep, no need for TargetSubject or TargetAuthority that I can think of.







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