[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]