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


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

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

Subject: RE: AuthN and Credentials

Some comments and search for a common ground:

>Our high-level goal here is not to burden SAML with the actual
>authentication process. By this I mean simply that there does not have
>to be anything in the SAML structure to support passing data between
>the principal and a relying party that says:

>        "I am Evan Prodromou, because I know this password: foo."
>       "I am Evan Prodromou, because I have the crypto private key
>         that makes this signature: [line noise]."
>        "I am Evan Prodromou, because I have this retinal pattern:
>         [line noise]."

Agreed. This was the main point of ISSUE:[UC-5-03:AuthNThrough];
no expression of authentication within SAML (I stole this characterization
from one of the respondents).

However, we are concerned with characterizing the "result" or
OUTPUT of an authentication step. This is the so-called credential
notion. In other words, a subject has been bound to a "name" thru
an authentication step. In particular, there are various standard 
forms of credential including:

       X509 Certificates
       X509 Distinguished Names
       Public Key
       Plain old string ("Identity token")
       <various other forms>

my main point is that we need to include some description of these
forms (and perhaps others) within SAML and that our requirements
need to reflect this.

>However, we do want to pass data between the principal and the relying
>party that says:

>        "I am Evan Prodromou, because the outlook.net security system
>        says that the holder of this token is Evan Prodromou, and here
>        is the token: [token]."

Actually, this statement is incredibly complex and probably needs
to be approached in steps. Some parts of it may
require further proof ("holder of the token is..") thru signature and
binding the token to a payload etc (cf. scoped assertion in S2ML).
But my interest here is in [token] which must be transparent and
carry some form of credential.

>It seems to me that each of these statements is "presenting
>credentials" in some way, and that the relying party, in verifying
>each statement, is performing "authentication." But it also seems that
>the last statement is the only one we really want to require SAML to
>be able to express.

>Is that fair to say? If so, how can we state that in a short 1-2
>sentence non-goal (or goal)?

I think my concern is that the way [R-AuthN] and [R-AuthZ] are written
there is no suggestion that we need to capture any standard credential
forms. This is a cause for concern as many authentication engines
generate precisely this type of credential. Further, many Az engines
can check various Az questions against such a credential. This is also
the background to [CR-5-01-1: StandardCreds]. 

>It also seems that we want an asserting party to be able to make
>statements about a principal, like so:

>        "Evan Prodromou is an employee at Outlook Technologies, Inc."
>        "Evan Prodromou plays the role of 'Software Architect.'"
>        "Evan Prodromou is a member of the group 'San Francisco
>         Office.'"

>For this go-round, we've been calling this kind of statement "AuthZ
>attributes" (because they are attributes of the principal that the
>relying party can use to make authz decisions).  If memory serves,
>these kind of statements are parts of "credential assertions" in
>S2ML. I'm wondering if that's a confounding factor in this discussion.

You are right, that has been part of the issue here. The B2B use-case
is somewhat in a different space; I will respond to that separately.

- prateek


>P.S. Please feel free to correct me if my terminology is off here.

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-use-request@lists.oasis-open.org

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

Powered by eList eXpress LLC