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

I'm not familiar with SAML so I don't understand why can't an 
application remove the Status element before getting the SAML library to 
verify the signature.
I mean, I agree that most likely applications aren't going to want to 
verify the signature itself. I just don't understand the concern.


Drummond Reed wrote:
> 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]