RE: Update: Contributed doc. browser bindings incl. Shibboleth

["Mishra, Prateek" <pmishra@netegrity.com>]

Some comments:

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

We can figure out how to package this issue appropriately.
Yes, I cannot stop implementors from doing a lot of
crazy stuff but there is a difference between MUST
haves in a specification and "you can also carry out
this further step which Javascript-disabled browsers
do not support".


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

Hmmmm. I disagree. As we are building a security protocol this feels
like a pretty big issue to me. My first cut would be that
confidentiality should be required in this context. Otherwise,
I can watch assertions fly by me and learn quite a lot
about the AP and RP and what sort of information they plan
to exchange.

>>>
>>>(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.

The point here is that the form (with the assertion 
contained within it) is now present within the local
state of the browser. People
can use the "back" button and access it and re-post
it to the destinaton site. Browsers
are used in the public arena (kiosks, airports), 
not just in private offices. People may complete
a short transaction and then walk away from the 
machine.

Even though limiting the lifetime of the assertion is 
helpful there still an issue of the form getting re-presented
to the destination site. I dont see this as an issue
of a hacker breaking the client as much as providing 
some safeguards against people re-posting the form. 



>>I guess, the one-time artifacts, do not solve the hidden ticket
>>stealer snooping a hacked client?
>>

Certainly it does not; no such claim has ever been advanced
to my knowledge, has it?

- prateek