OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [security-services] Proposed text: Authentication Method vs. SubjectConfirmation Met hod


Title: Proposed text: Authentication Method vs. Subject Confirmation Method

The editorial problem is that these elements are discussed in widely separate parts of the specification. I suspect that if this explanation is put in some introductory section, it will not be noticed by many readers. Therefore, I suggest the text below be repeated in each section, with a reversed initial sentence.

Therefore the section on Authentication Method would start:

Authentication Method should not be confused with Subject Confirmation Method.

{followed by text below}

And the section on Subject Confirmation Method would start:

Subject Confirmation Method should not be confused with Authentication Method.

{followed by}

Although both can contain some of the same values, their use is completely different. Authentication Method is a part of an Authentication Statement, which describes an authentication act which occured in the past. The Authentication Method indicates how that authentication was done. Note that the authentication statement does not provide the means to perform that authentication, such as a password, key or certificate.

In contrast, Subject Confirmation Method is a part of the Subject Confirmation, which is used to allow the Relying Party to confirm that the request or message came from the System Entity that corresponds to the Subject in the statement. The Subject Confirmation Method indicates the method which the Relying Party can use to do this in the future. This may or may not have any relationship to an authentication which was performed previously. Unlike the Authentication Method, the Subject Confirmation Method will usually be accompanied with some piece of information, such as a certificate or key, which will allow the Relying Party to perform the necessary check.

There are many Subject Confirmation Methods, because there are many different SAML usage scenarios. A few examples are:

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

2. There is no login, but an application request is digitally signed. The associated public key is used for confirmation.

3. The user logs in using Kerberos and a Kerberos ticket is used subsequently for confirmation. Notice that in this case although both the Authentication Method and the Subject Confirmation Method are Kerberos, what happens at each step is actually different. (See RFC 1510)


Hal
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC