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)


For those of you interested, here is some OpenXRI code that puts a SAML assertion into an XRD. This was written before my time and I never used it in any authority resolution server, so I'm not sure exactly what it does, but here it is:
http://openxri.svn.sourceforge.net/viewvc/openxri/openxri4j/trunk/openxri-server-logic/src/main/java/org/openxri/server/impl/TrustedServer.java?revision=336&view=markup

I agree with Will that the idea was mostly about the signature, and I guess SAML simply was quite fashionable back then :)

Markus

On Tue, Jun 23, 2009 at 12:08 AM, Will Norris <will@willnorris.com> wrote:
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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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