RE: Question re: core-12 Authenication Code

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Hal,

	In the example you cite I believe there would (or should) be
separate identifiers for the two uses.

Where I think they should be the same is as follows

Subject specification:
	The subject of this assertion may be authenticated using SSL
certificate client auth and the following key.


Authentication assertion:
	The subject of this assertion WAS authenticated by the issuer using
SSL certificate client auth.

	and...

	The subject of the assertion may be authenticated using the
following SAML artifact.



Where I think the anonymous auth conversation gets confused is the attempt
to differentiate the types of authentication. From the perspective of the
machine it really does not care if it is authenticating "Alice" or
"Anonymous". there is a gating function by which the machine establishes
whether the party requesting access is a sheep or a goat.


		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Monday, August 20, 2001 5:26 PM
> To: 'Hallam-Baker, Phillip'; 'George Robert Blakley III'
> Cc: 'security-services@lists.oasis-open.org'
> Subject: RE: Question re: core-12 Authenication Code
> 
> 
> I am not so sure this is a good idea. While there is 
> potential overlap in
> the identifiers, it is not really the same thing going on in 
> both cases.
> Let's consider some examples.
> 
> Suppose you are using Kerberos. First there is an initial 
> handshake, which
> involves a password or possibly PKI exchange, in any event 
> some long term
> credentials. Later, you confirm that some ticket belongs to you by
> demonstrating your knowledge of a session key. It is all 
> Kerberos, but the
> specifics are different.
> 
> Consider typical web interaction. Initial AuthN by 
> username/password, SSO
> via cookie or encoded URL.
> 
> Only in a PKI environment could both interactions be the same 
> and even here,
> the later interactions might well involve some symetric key 
> operation or
> bearer token for efficiency.
> 
> I will extend this in the anonymous subject thread.
> 
> Hal
> 
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > Sent: Monday, August 20, 2001 4:45 PM
> > To: 'George Robert Blakley III'; Hal Lockhart
> > Cc: Hallam-Baker, Phillip; 'security-services@lists.oasis-open.org'
> > Subject: RE: Question re: core-12 Authenication Code
> > 
> > 
> > 
> > The bigger issue is whether <Protocol> and 
> > <AuthenticationMethod> are the
> > same element (Say yes).
> > 
> > 	Phill
> > 
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> > 
> > 
> > > -----Original Message-----
> > > From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
> > > Sent: Monday, August 20, 2001 4:36 PM
> > > To: Hal Lockhart
> > > Cc: 'Hallam-Baker, Phillip'; 
> > 'security-services@lists.oasis-open.org'
> > > Subject: RE: Question re: core-12 Authenication Code
> > > 
> > > 
> > > I agree "authn method" is better.  In fact, I remember 
> > > complaining about
> > > authn type even as I was writing it down.
> > > 
> > > 
> > > --bob
> > > 
> > > Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 
> 436 1564)
> > > Chief Scientist, Security and Privacy, Tivoli Systems, Inc.
> > > 
> > > 
> > > Hal Lockhart <hal.lockhart@entegrity.com> on 08/20/2001 
> 02:36:39 PM
> > > 
> > > To:   "'Hallam-Baker, Phillip'" <pbaker@verisign.com>,
> > >       "'security-services@lists.oasis-open.org'"
> > >       <security-services@lists.oasis-open.org>
> > > cc:
> > > Subject:  RE: Question re: core-12 Authenication Code
> > > 
> > > 
> > > 
> > > Actually, I checked and the whiteboard transcription says 
> > > "AuthN type". I
> > > consider AuthN Method to be preferable.
> > > 
> > > Hal
> > > 
> > > > -----Original Message-----
> > > > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > > > Sent: Wednesday, August 15, 2001 6:48 PM
> > > > To: 'Hal Lockhart'; 'security-services@lists.oasis-open.org'
> > > > Subject: RE: Question re: core-12 Authenication Code
> > > >
> > > >
> > > > I think it came off the whiteboard.
> > > >
> > > > I would very much like to rename it, AuthenticationMethod
> > > > sounds good to me.
> > > > I think we should also rename the protocol element in
> > > > <Authenticator> to be
> > > > the same.
> > > >
> > > > [We can also change authenticator but that is another story 
> > > and first
> > > > someone needs to come up with a better name, HolderOfKey 
> > > being worse]
> > > >
> > > > Phillip Hallam-Baker FBCS C.Eng.
> > > > Principal Scientist
> > > > VeriSign Inc.
> > > > pbaker@verisign.com
> > > > 781 245 6996 x227
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > > > > Sent: Wednesday, August 15, 2001 5:29 PM
> > > > > To: 'security-services@lists.oasis-open.org'
> > > > > Subject: Question re: core-12 Authenication Code
> > > > >
> > > > >
> > > > > I was wondering why the term "Authentication Code" was
> > > > chosen for the
> > > > > consensus schema. I thought we had been using "Authentication
> > > > > Method" a term
> > > > > that seems more intuitive to me.
> > > > >
> > > > > Hal
> > > > >
> > > > > 
> ----------------------------------------------------------------
> > > > > To subscribe or unsubscribe from this elist use the 
> subscription
> > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > >
> > > >
> > > >
> > > >
> > > 
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > 
> > 
> > 
> > 
>

Phillip Hallam-Baker (E-mail).vcf