[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 ~ESP >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