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.
=wil
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
>
