RE: AuthN and Credentials - One Dissenting View

["Orchard, David" <dorchard@jamcracker.com>]

<wearHat type="standards:chair">Irving, I suggest that we will have a
minority opinions section or document.  I also suggest that we will have a
mechanism for indicating the relationship between publications and minority
opinions.  I expect that we will publish a "publication" document which
refers to the spec and minority opinions, and asks for public feedeback. 

This is a clear first candidate for a minority opinion.  It's also clear
that the WG intends to move on from this issue.
</wearHat>

Cheers,
Dave

> -----Original Message-----
> From: Greg Wilson [mailto:Greg.Wilson@baltimore.com]
> Sent: Thursday, March 01, 2001 4:49 AM
> To: security-services@lists.oasis-open.org
> Cc: Irving Reid
> Subject: FW: AuthN and Credentials - One Dissenting View
> 
> 
> [Forwarded on behalf of Irving Reid, whose subscription to
> this list is in flux at the moment. -- Greg]
> 
> -----Original Message-----
> From: Irving Reid [mailto:Irving.Reid@baltimore.com]
> Sent: Wednesday, February 28, 2001 7:20 PM
> To: security-use@lists.oasis-open.org;
> Subject: AuthN and Credentials - One Dissenting View
> 
> 
> As far as I know, I'm the main dissenter on 
> AuthN/Credentials; the one who
> voted that we _should_ include AuthN methods in SAML. I'll 
> try to explain
> why, with liberal cut&paste from the preceding messages. Even 
> if you skip
> the big hunk of exposition below, please read at least the 
> first quote and
> response; I suggest new wording for the AuthN related issues.
> 
> I really wish I could make it to the F2F; since I can't, I'm 
> going to have
> to be quite verbose in an attempt to avoid misunderstandings. 
> I hope that
> some of the people who _are_ able to attend will try to 
> represent these
> issues in my absence.
> 
> 
> As I see it, AuthN comes down to: A subject asserts their 
> "identity", and
> provides some reason why that assertion should be believed. 
> This combination
> of "identity" and "corroborating evidence" is what _I_ mean when I say
> "Credentials"; others may differ.
> 
> Typically, the assertion is "username = irving" and the 
> reason is "password
> = whatever". In more sophisticated cases, the assertion might be
> "Certificate = <big ASN1 blob>" and reason is "successfully 
> proved posession
> of the corresponding private key".
> 
> The direction SAML seems to be going is that the only sort of 
> credentials we
> support are "Identity = <arbitrary data>", "evidence = 
> Because foo.com's
> security service says so". As an aside, we may attach further 
> information so
> that foo.com's security service can explain _why_ they say so, but it
> doesn't make any fundamental difference to the validity of 
> the credential.
> 
> As far as I can see, there are two different arguments going 
> on. Some people
> are talking about the structure and content of the "foo.com's security
> service explains _why_ they say so" mentioned in the previous 
> paragraph. I
> don't see this as a big issue; we can do something like 
> provide standard
> URIs for the common cases, and allow people to invent their 
> own URIs for the
> cases we haven't thought of yet, and apply for 
> standardisation of them later
> (sort of an IANA / clearinghouse process); there are other 
> ways to solve the
> problem, and I'm sure we can pick one without serious contention.
> 
> 
> The other argument, and the one I really care about, is the 
> argument about
> whether having a single sort of SAML credential, which was 
> described in S2ML
> as a "Name Assertion", is sufficient. The reason I think it isn't is
> somewhat selfish: we perform authentication based on various sorts of
> credential over our PEP-PDP protocol. If SAML works out, we 
> intend to switch
> over to SAML as our native PEP-PDP protocol. When we do, if 
> SAML doesn't
> already support interesting forms of authentication we'll 
> immediately need
> to extend it. At that point we run into all the usual problems of
> non-standard extensions - poor interoperation, maintenance 
> headaches, etc.
> 
> In a more philosophical sense, these Name Assertions have to come from
> somewhere. They could appear out of thin air, or they could 
> be produced by a
> security service in response to some user input. Just for 
> argument, I'll
> call the latter case a "login service". I'm specifically 
> avoiding the term
> "authentication service", because to me "login" specifically 
> implies that
> the _user_ is supplying the evidence.
> 
> If we don't specify a login service in SAML, every one of us 
> is going to
> have to go off and design our own, or convert the one we've 
> already got so
> that it produces SAML name assertions. This means that 
> customers, system
> integrators, application infrastructure vendors, etc. are 
> still going to
> need custom code for each SAML implementation they want to 
> support, because
> 99+44/100% of their applications are going to require a login 
> service at
> _some_ point.
> 
> 
> Now for the specific responses to quoted text...
> 
> 
> > -----Original Message-----
> > From: Evan Prodromou [mailto:evan@outlook.net]
> > Sent: Wednesday, February 28, 2001 2:24 AM
> > To: 'UseCaseList '
> > Subject: Re: AuthN and Credentials
> > 
> > 
> > >>>>> "MP" == Mishra, Prateek <pmishra@netegrity.com> writes:
> > 
> >     Me> Our high-level goal here is not to burden SAML with 
> the actual
> > 
> >     MP> Agreed. This was the main point of
> >     MP> ISSUE:[UC-5-03:AuthNThrough]; no expression of 
> authentication
> >     MP> within SAML
> > 
> > Agreed, and it seems that the overwhelming majority of people in the
> > subcommittee agree (10-1!). Unfortunately, some people felt that the
> > wording of the non-goal was unclear or incorrect (at least that's my
> > guess as to why they voted against the particular non-goal). I think
> > that we need to find a better formulation that the dissenters could
> > agree to. Any dissenters have a suggestion?
> > 
> > My guess is that the quibble is about "authentication." If one is
> > being strictly formal, I think that accepting (say) an S2ML name
> > assertion as proof of identity is also a form of 
> "authentication." Is
> > there a clear way we can state the difference?
> 
> I think we could make this clearer by presenting more than 
> one issue. The
> first ones are positive requirements:
> 
> [R-NameAssertion] SAML Relying Parties must be able to 
> authenticate users
> based on Name Assertions.
> [R-NameAssertionInfo] SAML must provide a way for information about
> authentication to be associated with Name Assertions
> 
> 
> As for the non-goals:
> 
> [NON_GOAL-LoginService] SAML will NOT specify a login service 
> that provides
> Name Assertions in response to other forms of authentication.
> 
> [NON_GOAL-OtherCredentials] SAML will NOT specify a way to convey
> credentials other than Name Assertions.
> 
> As far as the actual content of Name Assertions:
> 
> [ISSUE-whatever-whatever-Authn]: [R-NameAssertionInfo] 
> requires the ability
> to attach additional information to Name Assertions. The envisioned
> application of this requirement is to include such things as "the
> authentication occurred at date-time X", "the authentication 
> method was
> biometric toe-smell", etc.
> 
> Resolutions:
> 1(a) SAML will define an extensible format for Name 
> Assertions that includes
> additional information
> OR
> 1(b) The aforementioned additional information will be 
> associated with Name
> Assertions using the oft-mentioned 'Authorization Data' SAML 
> object, with a
> reference to the Name Assertion. After all, what's so 
> different (at a strict
> data representation level, rather than semantically) about saying "The
> subject of <NameAssertion> is a member of group 
> 'Administrators'" or "The
> subject of <NameAssertion> authenticated using the method 
> identified as
> URI://saml.oasis.org/Toe-Smell"?
> 
> Independent of the choice of 1(a) or 1(b), the second issue 
> is whether to
> provide a standard (and extensible) way of describing the 
> authentication
> method; I think there are existing Issues that cover this question.
> 
> 
> > -----Original Message-----
> > From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> > Sent: Tuesday, February 27, 2001 6:33 PM
> > To: 'Orchard, David'; UseCaseList
> > Cc: Ahmed, Zahid
> > Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario
> > Variations
> > 
> > 
> > David,
> > 
> > if we exclude credentials from SAML we are going to be left
> > with very little in the way of identifying subjects. What is
> > the point of a name assertion if we do not have standard ways
> > of calling out "names" within it: public keys, string tokens, 
> > X509 DNs,
> > Certificates, and yes, even name and password (just another
> > secret credential). How can we have an interesting notion of 
> > an Az service
> > if there
> > are no standard credentials? 
> > 
> > > 
> > > I believe this was voted out of scope for SAML version 1.0, 
> > 
> > I have no reason to believe we have agreed not to standardize
> > credentials. It remains on the issue list (I believe with
> > an  8Yes/ 3No vote) and remains very much part of our
> > discussion.
> 
> I think this really ties back to the re-wording I suggested 
> above. I suspect
> that the 10-1 vote was really a vote against specifying a 
> Login Service. I
> would be surprised if anyone suggested that we shouldn't support
> "authentication" of Name Assertions, where "authentication" 
> means checking
> their structural validity by verifying signatures or such 
> like, deciding
> whether to believe the Name Assertion based on the identity 
> of the Asserting
> Party, and deciding what authorization response is 
> appropriate based on the
> identity (or anonymity) of the subject, the identity of the 
> Asserting Party,
> and the associated information related to the Name Assertion 
> (such as AuthZ
> Attributes or descriptions of authentication methods).
> 
> That said, the authentication I describe above really isn't 
> any of SAML's
> business. As long as we specify the _format_ of the Name 
> Assertion, the
> Relying Party is free to interpret the content however they 
> choose. They
> probably won't get many customers if their interpretation is 
> silly, but
> that's their problem.
> 
> Hmm. I just thought of another possibility - Are there people who
> interpreted the "Authentication Service" question as meaning 
> a service that,
> given a Name Assertion, returns an opinion as to the validity 
> of the Name
> Assertion? In that case, I can see why we're debating. 
> 'validity' of a name
> assertion, aside from at the lowest level of signature 
> verification, is
> entirely application-specific.
> 
> I suspect that what Prateek means when he says "standardise 
> credentials" is
> _not_ "standardise how SAML implementations are required to 
> assign trust to
> credentials", but rather "standardise how to describe what sort of
> credentials were presented". The second form is necessary in 
> order to make
> policy decisions such as "Allow <subject> to <verb> <object> 
> only if they
> logged in using an X9.9 Challenge-Response."
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>