[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Update: Contributed doc. browser bindings incl. Shibboleth
Prateek, >I would strongly recommend we leave JavaScript out of the >profile. Obviously, it is available as an optimization for >those who are willing to live a little dangerously. By bringing >it in formally we are opening the door to much controversy. By making a profile using dual-mode code, it will be a user's choice if you want automatic operation or not. Or do you mean that just by having JavaScript involved in something intended to be secure, would drag SAML's name in the dirt? This must be a very "tactical" move (which I'm bad at...) as implementators without doubt will add the JavaScript code anyway. Couldn't one handle it like RFC 2459 (X509-certs) that deprecates "legacy implementations" that use e-mail addresses in the Subject although this is 99.5% the actual deployment? :-) :-) I.e. tell how to do it but say its bad... >QUESTIONS: >(1) Do we need to mandate assertion confidentiality? Notice >that the assertion itself is loaded into the user's browser >and can therefore be "read" by the user. Should some form >of encryption be mandatory here? I would not make this mandatory as it would both complicate things, and there are probably not that many "secret" assertions. >(2) Assertion Integrity and Source Site Authentication: Given >that the assertion is travelling thru a third-party (user's >browser) it seems to me that it would be mandatory that >the assertion be digitally signed. That one I have no problems with. >(3) But what about replay attacks? Even with (1) and (2) >(signed assertion which has been encrypted) the assertion >and form can be copied and used from a completely different browser >by a completey different user. This is a hot potato for some people so I can only express some personal opionion. If the copy is made by the user, the user is performing a crime. At least if giving the assertion to another person. As this is like giving away your passwords I don't believe that it should be addressed. If the copy is the result of a hacked client, I wonder if you can trust anything on that machine. It could equally well have a key-board monitor and screen collector as well. Sort of impossible to cure. IMHO at least. >How can we guard against this? Notice, this is obviated >by the use of a "one-use artifact" >as found in the current web browser profile. There are no problems (we do this now BTW) to do one-time tickets but it requires state-holding as well. But not in the brutally simple PUSH scheme in my "Fat Browser Objects" slides. I guess, the one-time artifacts, do not solve the hidden ticket stealer snooping a hacked client? Anders
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC