Re: [security-services] comments on bindings-model-14

[Jeff Hodges <Jeff.Hodges@sun.com>]

> I dont see a problem with
> a lack of "password" subject confirmation as no such concept is
> involved in the example. 

Actually, it seems to me (and Joe) that example 1..

> 1. A user logs in with a password, and a temporary passcode or cookie 
> signed is issued and used for confirmation purposes to avoid repeated
> exposure of the long term password.

..does in fact implicitly refer to the old "password" confirmation method
wherein there was an associated <SubjectConfirmationData> value in the
assertion purportedly being some sort of password value. In any case, can we
please not use that example, and use a different one?

I've further massaged the proposed text -- some of the element names were old
ones etc. -- and concocted a new example 1. 

How's the below look?

thanks,

JeffH
-----

[SAMLcore] defines <ConfirmationMethod> as part of the <SubjectConfirmation>
element.  The <SubjectConfirmation> element SHOULD be used by the Relying
Party to confirm that the  request or message came from the System Entity
that corresponds to the Subject in the statement.  The <ConfirmationMethod>
indicates the specific method which the Relying Party should use to make
this judgement. This may or may not have any relationship to an
authentication that was performed previously. Unlike Authentication Method,
<ConfirmationMethod> will often be accompanied with some piece of
information, such as a certificate or key, in the <SubjectConfirmationData>
and/or <ds:KeyInfo> elements, which will allow the Relying Party to perform
the necessary check.

It is anticipated that profiles and bindings will define and use several
different values for <ConfirmationMethod>, each corresponding to a
different SAML usage scenario.  Some examples are:

1. A website employs the browser/artifact profile of SAML to sign-in a user.
The <ConfirmationMethod> in the resulting assertion is set to
urn:oasis:names:tc:SAML:1.0:cm:artifact-01.

2. There is no login, but an application request sent to a relying party
includes SAML assertions and is digitally signed. The associated public key
from the <ds:KeyInfo> element is used for confirmation.

---
end