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

[Anders Rundgren <anders.rundgren@telia.com>]

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