RE: Authenticator/HolderOfKey element name

[Kelvin Beeck <kelvin.beeck@talkingblocks.com>]

Hmmm,

Is there any reason why we can't used the term PublicCredentials,
RequiredCredentials or similar.

I think this covers what you are trying to express and is a well understood
term.

> -----Original Message-----
> From: Chris McLaren [mailto:cmclaren@netegrity.com]
> Sent: Tuesday, July 24, 2001 10:56 AM
> To: 'Security-Services (E-mail)'
> Subject: RE: Authenticator/HolderOfKey element name
>
>
> Let me start by saying that I agree this needs a new name,
> particularly when
> considering the non-crypto use cases Phillip proposes.
>
> Of these suggestions, I like 3 the most.
>
> Tagging it as being related to the Subject clears up some
> confusion, but the
> term Authenticator is still ambiguous between "Thing that
> authenticates" and
> "Entity that suthenticate", and this carries over to
> SubjectAuthenticator
> ("Thing that authenticated the subject" vs "Entity that
> authenticates the
> subject".
>
> That would lead me to choice 4, except that "profile" is such
> a loaded term.
>
> What about something like SubjectAuthenticatorInfo,
> SubjectAuthenticationInfo, SubjectAuthenticationData, etc.?
>
> C.
>
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > Sent: Tuesday, July 24, 2001 2:42 PM
> > To: Security-Services (E-mail)
> > Subject: Authenticator/HolderOfKey element name
> >
> >
> > Issue - What to call the data item that identifies the
> > Subject by reference
> > to some form of Authentication data.
> >
> > The element is useful in applications where privacy is an
> > issue where we do
> > not want to identify the subject by name but instead use some other
> > characteristic that identifies them, possibly for a limited
> > time (one time
> > use credentials).
> >
> > There may be no perfect name for the element.
> >
> > Alternatives
> >
> > 1) Authenticator
> > 	The original name. Objection raised was that the term may be
> > confused with other uses of the term 'Authenticator', such as
> > a message
> > authenticator. Also the term has been appropriated in Kerberos.
> >
> > 2) HolderOfKey
> > 	The core10 name. Object is that the means of authenticating the
> > subject may not be limited to cryptographic means, the
> > subject may be the
> > holder of a SAML artifact or a Kerberos Ticket which are only
> > 'keys' in a
> > loose sense. Also the person may be authenticated by means of
> > a biometric
> > profile (fingerprint, iris scan) which again is not a key and
> > it is not
> > 'holdership' that is at issue.
> >
> > 3) SubjectAuthenticator
> > 	The element is a subject authenticator, so extending
> > the name may
> > get round the objections to (1). Possible objection on
> > grounds of verbosity,
> > after all doesn't the enclosing element implicitly scope
> the internal
> > elements so is <Subject><SubjectAuthenticator> somewhat
> > repetative, but hey
> > this is XML.
> >
> > 4) AuthenticationProfile
> > 	Another alternative
> >
> > In Quaker poll fashion I can live with 1, 3 or 4.
> >
> >
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
>