- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Mon, 04 Jun 2012 14:35:29 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On 06/04/2012 01:47 AM, Mark Nottingham wrote: > > On 02/06/2012, at 10:05 PM, Amos Jeffries wrote: >> >> -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. > > > I'd thought the issue was that we already use "credentials" to denote what-goes-on-the-wire, not what-goes-into-the-ua-and-is-munged-to-get-onto-the-wire. If we don't need to make a distinction between the two, I agree that credentials is fine. That's exactly the distinction I was trying to get at. Thanks for stating it better. Like I said I don't think its a major deal but maybe it'd be worth making that distinction in the text but leaving things alone otherwise? The benefit, I think, is simply to help get developers out of the "send password" mindset a bit. (Yes, there's unfortunately a windmill, and yes, I'm tilting at it;-) Maybe something like: "The term credentials is used here for the bits sent in the protocol, even though those bits are, in general, the result of applying some function to a set of credentials. For example, with digest authentication, the "real" credential is the password, but the set of bits sent are the output of a digest function and not the actual password. In that example, the bits sent are almost as sensitive as the underlying credential, but with a putative digital signature based scheme, then underlying credential (the private key) would be highly sensitive, whereas the signature would not. Developers ought ensure that appropriate steps are taken to protect these values." I'd be fine with s/ought/MUST/ or s/ought/SHOULD/ if someone wanted, but its not really testable in the protocol. S > -- > Mark Nottingham http://www.mnot.net/ > > > > >
Received on Monday, 4 June 2012 13:36:11 UTC