[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Authenticator/HolderOfKey element name
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC