Subject: Terminology: "credentials"

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jun 2012 12:28:48 +0200

On 2012-05-31 16:16, Stephen Farrell wrote:
> ...
>> It's the term we currently use throughout.
>
> I said feel free to ignore me, not to feel free to give a
> non-answer:-)
>
> I can understand that it might take work to change, and
> that that might not be worthwhile. But if in fact its not
> the right term for some of those uses then it might be
> worth changing to avoid future confusion.
>
> Just saying "its that way now" isn't an answer to the
> question asked.
> ...

OK, I'll rephrase it: if you believe the term is misleading than we need 
to discuss this *separately* from this issue, as we use the term 
throughout the spec consistently.

My personal point of view is that the term is good enough and changing 
out might cause confusion. That being said, I'm ready to be convinced 
otherwise.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jun 2012 12:30:15 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jun 2012 12:37:07 +0200

On 2012-05-31 14:20, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/349>
>
> Proposal: change
>
>>     Both the Authorization field value and the Proxy-Authorization field
>>     value consist of credentials containing the authentication
>>     information of the client for the realm of the resource being
>>     requested.  The user agent MUST choose to use one of the challenges
>>     with the strongest auth-scheme it understands and request credentials
>>     from the user based upon that challenge.
>
>
> to
>
> """

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/349/>

Feedback appreciated, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 03 Jun 2012 00:05:30 +1200

On 2/06/2012 10:30 p.m., Julian Reschke 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.
>>>> """
>>>

-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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jun 2012 10:45:47 +1000

> -1; if we change the terms we should do so consistently.

I thought "details" captured a certain vagueness that would help in this particular case. YMMV.

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jun 2012 10:47:08 +1000

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 04 Jun 2012 02:57:35 +0200

>I thought "details" captured a certain vagueness that would help in this particular case. YMMV.

I agree with Julian in that if we want to consider changing the termino-
logy, we should do that in a dedicated thread rather than arguing about
the terms in the particular example, short of a rationale why this par-
ticular instance is exceptional. I don't think, in any case, "details"
would be a good replacement.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jun 2012 10:58:23 +1000

> would be a good replacement.

See my subsequent message; my understanding was that this is a special case, because it's not talking about what's happening on the wire.

Cheers,

---

From: David Morris <[email-masked]>
Date: Sun, 3 Jun 2012 22:54:54 -0700 (PDT)

On Mon, 4 Jun 2012, Mark Nottingham wrote:

> See my subsequent message; my understanding was that this is a special 
> case, because it's not talking about what's happening on the wire.

I don't see a reason to call what is on the wire anything different than 
what is provided by the user. It is encoded according to the rules of
the authentication method. There is no clarity that I can divine with
the additional complexity.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Jun 2012 14:35:29 +0100

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

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

---

From: James French <[email-masked]>
Date: Thu, 31 May 2012 16:20:12 +0000

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

Perhaps this phrase "ought to" should be an all-caps (RFC 2119) SHOULD?

---

From: "Musatov, Martin - CW" <[email-masked]>
Date: Mon, 4 Jun 2012 14:58:07 +0000

Why is a great deal of the content on the HTTP working seem so tongue and cheek, people making obscure gestures with double sets of quotes, blank lines, spaces and capitalization?

It reminds me of:

Proverbs 6:13
He winks with his eyes and strikes with his feet and he signals with his fingers,

Just an observation

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jun 2012 10:31:11 +0200

> the additional complexity.

Change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1669>.

We can discuss terminology, but this should happen in a separate thread.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Jun 2012 17:25:23 +1000

... and I'm closing the WGLC ticket. Thanks.

On 05/06/2012, at 6:31 PM, Julian Reschke wrote:

> Change applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1669>.
>