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: ED07 Issue #3: Status element and SAML signatures


In his comments on ED06, Gabe brought up another issue:

 

Line 2871 – here’s the major problem – screwing around with the SAML enclosed element signature profile is a recipe for implementation disaster – I think most of the libraries out there do the saml signature stuff and that’s it – modifying the way signatures are done seems to me like a potential disaster. One solution might be to move the Status element inside the SAML element that is removed by the enclosed signature transform (I forget the details). But the way it is now is that we’ll have to rewrite saml libraries to remove the Status element – blech. I’m worried about implementation of SAML digsig stuff in lots of languages in the first place (like Ruby, Python, etc)

 

************

I discussed this with Gabe. The practical issue is this: how many apps are going to want to do SAML signature checking on an XRD themselves vs. having an XRI resolver they trust do it for them?

 

If the answer is “very few or none” (which I what I believe will be the case), then this becomes a non-issue, because the XRI resolver will check the signature based on exactly the XRD it receives back from the server, and only afterwards will it add the Status element. The consuming application isn’t going to care; it just knows it asks for saml=true on the request and accepts a response where the Status code=”100”.

 

Therefore I propose we sidestep the whole issue as follows:

 

1) Recommend that consuming applications use a trusted XRI resolver to check SAML signatures, and simply rely on the output of the XRI resolver in the Status element that is added AFTER signature verification is complete.

 

2) If for any reason a consuming application wants to verify an XRD signature itself, it should take the outcome of the trusted resolver and do its own call to the authority server for each XRD it wants to independently verify. That way the result will not have any additional Status element added by the resolver.

 

************

I’m going for the presumptive close on this issue: please post if you DO NOT agree with this solution. Otherwise I’ll write it into ED07.

 

=Drummond

 



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