Subject: Re: [OAUTH-WG] Mandatory-to-implement HTTP authentication scheme

From: Mike Jones <[email-masked]>
Date: Thu, 17 Nov 2011 08:32:49 +0000

Terminology correction:  This discussion was actually about HTTP authentication schemes (Bearer, MAC, etc.), not token types (JWT, SAML, etc.).  I've changed the subject line of the thread accordingly.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, November 17, 2011 12:29 AM
To: oauth WG
Subject: [OAUTH-WG] Mandatory-to-implement token type

Stephen, as AD, brought up the question of mandatory-to-implement token types, in the IETF 82 meeting.  There was some extended discussion on the point:

- Stephen is firm in his belief that it's necessary for interoperability.  He notes that mandatory to *implement* is not the same as mandatory to *use*.
- Several participants believe that without a mechanism for requesting or negotiating a token type, there is no value in having any type be mandatory to implement.

Stephen is happy to continue the discussion on the list, and make his point clear.  In any case, there was clear consensus in the room that we *should* specify a mandatory-to-implement type, and that that type be bearer tokens.  This would be specified in the base document, and would make a normative reference from the base doc to the bearer token doc.

We need to confirm that consensus on the mailing list, so this starts the discussion.  Let's work on resolving this over the next week or so, and moving forward:

1. Should we specify some token type as mandatory to implement?  Why or why not (*briefly*)?

2. If we do specify one, which token type should it be?

Barry, as chair
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Matt Miller <[email-masked]>
Date: Thu, 17 Nov 2011 17:24:51 +0800

Further clarification (-:  This is not (or shortly will not be) limited to HTTP.  There is work to use OAUTH over SASL, which opens it up to a much much broader audience (e.g. IMAP, SMTP, and XMPP).

> 1. Should we specify some token type as mandatory to implement?  Why or why not (*briefly*)?

Yes.  I believe it is necessary to provide a baseline for implementors, and will help make the "80% rule" easier; if "everyone" supports <x> then I will find client, authorization, and resource software that will "just work".  I think this becomes even more important as OAuth is used with well-established resource servers (e.g. cloud-based XMPP service).

> 2. If we do specify one, which token type should it be?

I personally am ambivalent.

> 2. If we do specify one, which token type should it be?

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 17 Nov 2011 11:30:12 +0000

Making the draft-ietf-oauth-v2-bearer mandatory to implement gets us a bearer (unknown content and format) token from the authorization server, for the resource server this gets us a authentication scheme of bearer (unknown content and format) token, not sure where this gets us towards interop as the content and format will be specific to authorization and resource server.

I don't fully understand the requirement for this mandatory to implement item beyond the fact that everyone has to implement bearer tokens of unknown content and format.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Miller
Sent: Thursday, November 17, 2011 1:25 AM
To: Mike Jones; Barry Leiba
Cc: oauth WG
Subject: Re: [OAUTH-WG] Mandatory-to-implement HTTP authentication scheme

- m&m

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Nov 2011 10:34:33 -0300

Unless I am missing something this is about the HTTP authentication scheme that the protected resource MUST support.   Token type is a bit of a misdirection.

While it would be possible to use some profile of bearer with those other protocols,  making a specific HTTP binding of MAC or Bearer  MTI would preclude ever having a conforming version for  SMTP.

Not that there aren't other HTTP specific things in the spec that may also be an issue.

I don't think that having a MTI token type/http authentication scheme alone gets us interoperability.
I don't even know if OAuth 2.0 interoperability between two unrelated systems is a goal.
Other specs like OpenID Connect have that goal.

If I have to pick one authentication scheme as MTI for the protected resource it would be Bearer.

John B.

---

From: William Mills <[email-masked]>
Date: Thu, 17 Nov 2011 08:22:07 -0800 (PST)

> 1. Should we specify some token type as mandatory to implement?  Why or why not (*briefly*)?

Briefly... No.  Because it doesn't actually solve the whole problem and mandates a particular security model.  

Not so briefly....  

It tries to solve the client-to-server interoperability by ensuring that there is a supported auth type, but in fact it will mandate a security model which is something the core spec has specifically avoided.  Signed tokens (MAC etc.)  and bearer type tokens (Bearer, JWT, etc.) are different in their security characteristics.

It also does not solve at all the problem of token compatibility, which is somehting the auth and protected service endpoints have to agree on within a realm.  It is difficult to justify that there has to be realm to realm compatibility.

What we actually need to support as MTI is that the clients can discover what authentication schemes are supported for the endpoints they want to access and select a method they support.  This is very much in the SSL model of choosing key exchange and cipher suites.

-bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, November 17, 2011 12:29 AM
To: oauth WG
Subject: [OAUTH-WG] Mandatory-to-implement token type

Barry, as chair