XRD Signing (and SAML)

[Will Norris <will@willnorris.com>]

So, to follow up on one of my action items from this last weeks call,  
I've been looking into how the equivalent of <TargetSubject /> and  
<TargetAuthority /> were used previously in XRI Resolution.  The good  
news is that I have a better understanding of how they were used.  The  
bad news is that I have no idea *why* on earth they would have been  
used in this manner.

On the last call, I pointed out that I believed these trust elements  
were only being used when embedding SAML into the XRD.  That much was  
true (I still think), but what I didn't realize was why one would  
embed a SAML assertion into an XRD.  Put quite simply, it was for the  
signature.  If you read through section 10.2 of XRI Resolution [0],  
you'll notice that SAML was leveraged here because it already had a  
well defined method for calculating a digital signature.  Extra steps  
were taken to require that certain parts of the SAML Assertion matched  
up with certain parts of the containing XRD.  But essentially, the  
only value the embedded assertion brought to the document was the  
signature itself.  This is *exactly* what we've spent that last few  
weeks on, except that we're moving the digital signature directly  
under the XRD element, instead of bringing SAML along for the ride.

[0]: http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html#_Toc192004315

Now, as best as I can tell, there is really no other value in using  
SAML inside of an XRD (at least how it was defined by XRI  
Resolution).  Does anyone know of any other reasons?  Does anyone know  
why this approach was taken rather than what we're now doing...  
putting the <ds:Signature /> directly under the <XRD />?  I've read  
through all of Section 10 of XRI Resolution, and do not believe there  
are any use cases which cannot be accomplished using the current  
proposed XRD schema (with the one addition I mention below) and the  
current proposed XRD Signature.  If anyone does have a use-case that  
is not covered, then *please* let me know.


## Possible use-case for <TargetAuthority /> ##

In order to support the XRD chaining model of trust, we must embed the  
public key used to sign one XRD inside the <Link /> element of another  
XRD.  XRI Resolution called for 0 or 1 <ds:KeyInfo /> elements under  
<xrd:Service />.  Allowing for only a single <ds:KeyInfo /> doesn't  
work too well when you are approaching the expiration date for a  
certificate, so I believe we need to allow for multiple.  We can  
either allow for 0 or more <ds:KeyInfo /> elements under <Link />, or  
we can go ahead and specify some other wrapper element  
(<TargetAuthority />, or some other name) that contains these  
<ds:KeyInfo /> elements.  One of the advantages we noted of having a  
separate "XRD Trust" namespace was to dissuade people from abusing  
it.  <ds:KeyInfo /> is already in the XML DSig namespace, so is that  
enough?



## 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.


Thoughts, comments, feedback?

-will