- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 03 Jun 2012 00:05:30 +1200
- To: ietf-http-wg@w3.org
On 2/06/2012 10:30 p.m., Julian Reschke wrote: > On 2012-06-01 02:50, Mark Nottingham wrote: >> >> On 31/05/2012, at 11:59 PM, Stephen Farrell wrote: >>>> """ >>>> Both the Authorization field value and the Proxy-Authorization >>>> field value contain the client's credentials for the realm of the >>>> resource being requested, based upon a challenge received from the >>>> server (possibly at some point in the past). When creating their >>>> values, the user agent ought to do so by selecting the challenge >>>> with what it considers to be the most secure auth-scheme that it >>>> understands, obtaining credentials from the user as appropriate. >>>> """ >>> >>> Could be a can of worms so feel free to ignore me >> >> I suspect it's a bit of one. >> >>> but is >>> the term credentials there correct? Perhaps authenticator >>> would be better? If we do manage to get better schemes >>> defined then someday not all of these would allow derivation >>> of an underlying password credential. >> >> >> How about a nice generic "details", as in "obtaining details from the >> user as appropriate."? >> ... > > -1; if we change the terms we should do so consistently. > > Best regards, Julian > -1 as well. "credentials" carries clear message of something which carries authority and must be treated carefully. "details" does not. As of right now wikipedia have a nice clear definition: " A credential is an attestation of qualification, competence, or authority issued to an individual by a third party with a relevant or de facto authority or assumed competence to do so. Examples of credentials include academic diplomas, academic degrees, certifications, security clearances, identification documents, badges, passwords, user names, keys, powers of attorney, and so on. " Personally I think "credentials" is clearly data while "authenticator" implies a process actor. Switching that around could add a lot of confusion. +1 for the status-quo. AYJ
Received on Saturday, 2 June 2012 12:06:07 UTC