RE: Authenticator/HolderOfKey element name

[Chris McLaren <cmclaren@netegrity.com>]

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
>
>
>
>