Subject: [OAUTH-WG] Revised Section 3

From: Thomas Hardjono <[email-masked]>
Date: Thu, 14 Apr 2011 16:16:40 -0400

Eran, Folks,

Per my promise at the last IETF80 to improve the text
for Section 3, attached is the XML version and TXT file.

As you will see, I did not introduce any major changes but
only clarifications and explanations.
I used the text from draft-11, which I believe has
the more complete text.

Since many/most shared secret schemes are not assertion-based 
schemes, I split Section 3.2 into two new sections: 
- one section on shared secret schemes (eg. EKE, PAKE, OTP,
   etc, etc numerous)
- another section on assertions proper.

The additional references are located at the end
of the attached TXT file.

Hope these changes are acceptable.

cheers,

/thomas/

__________________________________________
Thomas Hardjono
MIT Kerberos Consortium
email:  hardjono[at]mit.edu
desk:   +1 617-715-2451
__________________________________________

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 13:19:34 -0700

To make discussion easier, here is the proposed text:

[NOTE: Text for the following Section 3 is based on OAUTH draft-11]

3.  Client Credentials

   When interacting with the authorization server, the client identifies
   itself using a set of client credentials which include a client
   identifier and other properties for client authentication.  The means
   through which the client obtains its credentials are beyond the scope
   of this specification. Some authentication 
   schemes require the client to undergo registration with the
   authorization server.

   Due to the nature of some clients, authorization servers SHOULD NOT
   make assumptions about the confidentiality of client secrets without
   establishing trust with the client.  Although it is difficult for 
   servers to ascertain the security capabilities of clients, in general 
   authorization servers SHOULD NOT issue client secrets to clients incapable 
   of keeping their secrets confidential.

   The authorization server MAY authenticate the client using any
   appropriate set of credentials and authentication schemes.  The
   client MUST NOT include more than one set of credentials or
   authentication mechanism with each request.

   Although authentication schemes and their protocol implementations 
   are out of scope, this specification seeks to support a broad 
   selection of authentication schemes that are currently deployed 
   today and that may be deployed in the future.

3.1.  Client Password Credentials

   Client password credentials use a shared symmetric secret to
   authenticate the client.  The client identifier and password are
   included in the request using the HTTP Basic authentication scheme as
   defined in [RFC2617] by including the client identifier as the
   username and client password as the password.

   For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=i1WsRn1uB1&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

   Alternatively, the client MAY include the password in the request
   body using the following parameters:

   client_id
         REQUIRED.  The client identifier.

   client_secret  REQUIRED.  The client password.

   For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&client_id=s6BhdRkqt3&
     client_secret=gX1fBat3bV&code=i1WsRn1uB1&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

   The authorization server MUST accept the client credentials using
   both request parameters and the HTTP Basic authentication scheme.
   The authorization server MAY support additional authentication
   schemes suitable for the transmission of password credentials.

3.2.  Shared Secret Credentials

   Beyond client password credentials, there is a broad family 
   of authentication schemes based on the notion of shared secrets.  
   In these schemes the primary aim is for the client to prove 
   possession of the shared secret. In the current OAUTH 2.0 context, 
   shared secret credentials are different from assertion credentials 
   (see below) in that here the client does not have to 
   provide any assertions or claims. 
   
   Within the family of authentication schemes based on the pairwise 
   sharing of secrets there are a variety of protocols that have 
   been deployed.  These include challenge-response protocols 
  (e.g. CHAP [RFC1994]), password-authenticated key agreement 
   protocols (e.g. EKE [REF]) and various embodiments 
   of the one-time password (OTP) protocols (e.g. [RFC2289]).

   These authentication protocols 
   are out of scope of this specification, but in deployment 
   of these authentication schemes with OAUTH 2.0, the authorization 
   server MUST accept the client credentials using
   both request parameters and the HTTP Basic authentication scheme.

3.3  Client Assertion Credentials

   The term assertion (or signed assertion) refers to a statement or 
   claim made by a trusted third party regarding a given subject 
   at a given moment in time. Typically an assertion is digitally 
   signed by its issuer in order to provide source-authenticity 
   and integrity protection. There are a number of vehicles for 
   the implementation of assertions.  
   Examples include X.509 subject and attribute certificates 
   [RFC3280,RFC5755], SAML 2.0 assertions [OASIS.saml-core-2.0-os], 
   Claims [OASIS.imi-identity-1.0], Kerberos service tickets [RFC4120] and others.  
   Their differences typically lie in their semantic expressiveness, 
   syntactic complexity and size.

   In OAUTH, client assertion credentials provide an extension point 
   by which the authorization server can authenticate a client by validating 
   a signed assertion issued by a third party (assertion issuer), 
   which is trusted by both the client and the authorization server.

   A client must obtain an assertion (such as
   a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer
   or may in some cases self-issue an assertion.  
   The format of the assertion, the process by
   which an assertion is obtained, and the method of validating an
   assertion are defined by the assertion issuer and the authorization
   server, and are beyond the scope of this specification. However, for 
   the purposes of the authorization server validating the identity of 
   a client, the assertion presented by the client SHOULD contain 
   at least the following information:

   o  Identity of the client.
   o  Identity of the issuer.
   o  Method of authentication used by the issuer to 
      authenticate the client (RECOMMENDED).
   o  Time of authentication of the client by the issuer (RECOMMENDED).
   o  Time of assertion issuance and validity period of assertion.
   o  Digital signature of the issuer.
   o  An indication (explicit or implied) as to the means by which 
      the client demonstrates its right to present the assertion (RECOMMENDED).

   When using a client assertion, the client includes the following
   parameters:

   client_assertion_type  REQUIRED.  The format of the assertion as
         defined by the authorization server.  The value MUST be an
         absolute URI.

   client_assertion  REQUIRED.  The client assertion.

   For example, the client sends the following access token request
   using a SAML 2.0 assertion to authenticate itself (line breaks are
   for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=i1WsRn1uB1&
     client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D&
     client_assertion_type=
     urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

   When obtaining an access token using a client assertion together with
   an authorization code (as described in Section 5.1.1), a mechanism is
   needed to map between the value of "client_id" parameter used to
   obtain the authorization code, and the client assertion.  Such a
   mechanism is beyond the scope of this specification, but MUST
   be specified for any client assertion type used in combination with
   an authorization code.

   The authorization server MUST reject access token requests using
   client assertion credentials that do not contain HMAC or signed
   values that:

   o  State the assertion was specifically issued to be consumed by the
      receiving endpoint (typically via an audience or recipient value
      containing the receiving endpoint's identifier).

   o  Identify the entity that issued the assertion (typically via an
      issuer value).

   o  Identify when the assertion expires as an absolute time (typically
      via an expiration value containing a UTC date/time value).  The
      authorization server MUST reject expired assertions.

References

RFC1994.  PPP Challenge Handshake Authentication Protocol (CHAP), IETF Standards Track, August 1996.

S. M. Bellovin; M. Merritt (May 1992). "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks". Proceedings of the 1992 IEEE Symposium on Research in Security and Privacy, Oakland, CA.

RFC4120.  The Kerberos Network Authentication Service (V5), IETF Standards Track, July 2005.

OASIS Identity Metasystem Interoperability Version 1.0, Oasis Standard, July 2009.   URL: http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.html#_Toc229451842

RFC5755  An Internet Attribute Certificate Profile for Authorization, IETF Standards Track, January 2010. 

RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF Standards Track, April 2002.

RFC2289.  A One-Time Password System. IETF Standards Track, February 1998.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 14:56:07 -0700

Thanks Thomas!

My notes below are not aimed specifically at Thomas but at those seeking to have this section included. I'm going to skip any editorial feedback as I will make those changes if and when incorporating this text into the v2 specification. I will say that the new section 3.2 belongs largely in the introduction of section 3.

>    authentication mechanism with each request.

Need to make it explicit that no client authentication scheme is mandatory to implement.

>    today and that may be deployed in the future.

This statement is just not true. This specification may seek to keep client authentication out of scope but by defining two such mechanisms in section 3, it clearly fails to keep them out of scope.

> 3.1.  Client Password Credentials

This section should be named "Using HTTP Basic access authentication scheme". The parameters defined are just a hack to align Basic with the deployed reality of using parameters instead of the header.

>    body using the following parameters:

Need to add a note here that using the parameter alternative is deprecated or NOT RECOMMENDED. If we are going to bastardize HTTP Basic, we should do it in a responsible way and discourage people from using it. There is not a single reason why clients can't use HTTP Basic to transmit these credentials (if you have requirements showing otherwise, please share).

>    schemes suitable for the transmission of password credentials.

This is not true. There are no requirements for what authentication schemes the authorization server MUST or SHOULD accept.

>    both request parameters and the HTTP Basic authentication scheme.

I don't understand how these other symmetric secret schemes work with Basic.

>       the client demonstrates its right to present the assertion

The entire section is marked as SHOULD which is equal to RECOMMENDED. This is an odd combination of "double SHOULD" on some items.

>    client_assertion  REQUIRED.  The client assertion.

Since this section does not claim to be the only valid way to authenticate a client using assertions (as other *real* HTTP schemes may provide that facility), the REQUIRED parameters should be limited to those using *this* mechanism, not to 'using a client assertion'.

>    be specified for any client assertion type used in combination with

This MUST is pointless and should be removed. We should not include any MUST which cannot be verified and enforced (I need to review the rest of the document for such normative requirements).

Here, since no registration process is provided for assertion types, and none of the vendors demanding this facility have published (or indicated their intention to publish) documents for any particular assertion type, where exactly is this MUST to be enforced? There is just no point. It is enough to say that this is something they need to consider.

>       authorization server MUST reject expired assertions.

This is where things fall apart. This looks like normative language, and clearly intents to be, but has no real way of being implemented by any general purpose library. If this section (client assertions) is to be added to the specification, this entire last part should be converted to a security consideration section, not a pretend attempt to define real security requirements.

The security of this entire proposal rests on being able to enforce these requirements, but the specification does not offer any useful information for implementers to do so.

In practice, this invents a new HTTP authentication scheme. The test we must apply here before adding this section to the document is whether it would pass IETF scrutiny if it was presented as a new, standalone, HTTP authentication scheme (regardless of how it transmits the credentials using parameters or header). Before including it, I would like to see a statement from the AD stating that the text is acceptable to the IETF security standards, and that it is suitable for use as a generic HTTP authentication scheme. If it is acceptable here but not with other HTTP requests, we need to make that clear (though that would be pretty bad).

Here is one counter proposal to this. Define the two parameters 'client_assertion_type' and 'client_assertion', and specify a required process for publishing specifications using them for use with well-defined assertion formats. This way, the community can enforce sane security standards which this section clearly fails to accomplish (no matter hard it tries, and it does try).

How is this different from the grant type extension point (which does not require any such publication)? With the grant type extension point, we clearly label it an extension, and take no position as to what it may contain and to its level of security. Here however, the text clearly creates the illusion of security, but doesn't provide enough detail as how to specifically accomplish that in practice.

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Apr 2011 16:06:46 -0600

On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote:

<snip/>

> In practice, this invents a new HTTP authentication scheme.

Eran, during the WG meeting in Prague you said the same thing, and I
tend to agree. Yes, client authentication is a good thing, but given
that OAuth happens over HTTP I don't see why we can't just use existing
HTTP authentication schemes. If BASIC and DIGEST aren't good enough,
then someone needs to develop a new HTTP authentication scheme. However
that's not a job for the OAuth WG as far as I can see...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 15:16:35 -0700

Which reminds me:

Section 3.1 needs to include a clear MUST use TLS when using this authentication method. While this is covered by the requirement to use TLS where OAuth utilized this client authentication scheme (token endpoint), the introduction of client_id and client_secret do invent a new HTTP authentication scheme alongside Basic, and we need to make sure people don't try and apply it elsewhere without TLS (we know someone will).

EHL

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Thursday, April 14, 2011 3:07 PM
> To: Eran Hammer-Lahav
> Cc: Thomas Hardjono; oauth
> Subject: Re: [OAUTH-WG] Revised Section 3
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Apr 2011 15:40:31 -0700

+1

There is the issue of how a client app 'bootstraps' its own credential.  It could be that it authenticates by some other RFC (like 2617 Basic Auth), or some other method.  E.g. would be nice to have a way for client apps to obtain either the equivalent of client_assertion, or even a MAC token representing just the client security context (a turtles-all-the-way-down approach).

Regardless, I agree this isn't part of the core OAuth specification.

Phil
[email-masked]

On 2011-04-14, at 3:06 PM, Peter Saint-Andre wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 15:46:37 -0700

My current project uses MAC authentication for client authentication at the token endpoint. I would be helpful if people explicitly express their views on the proposed text, and whether they support or object to it.

EHL

> From: Phil Hunt [mailto:[email-masked]]
> Sent: Thursday, April 14, 2011 3:41 PM
> To: Peter Saint-Andre
> Cc: Eran Hammer-Lahav; oauth
> There is the issue of how a client app 'bootstraps' its own credential.  It could
> be that it authenticates by some other RFC (like 2617 Basic Auth), or some
> other method.  E.g. would be nice to have a way for client apps to obtain
> either the equivalent of client_assertion, or even a MAC token representing
> just the client security context (a turtles-all-the-way-down approach).
> 
> > that OAuth happens over HTTP I don't see why we can't just use
> > existing HTTP authentication schemes. If BASIC and DIGEST aren't good
> > enough, then someone needs to develop a new HTTP authentication
> > scheme. However that's not a job for the OAuth WG as far as I can see...
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 15:49:32 -0700

(sorry for the fragmented post)

And to be clear, my feedback is in no way an endorsement of including this text. I am still strongly opposed to it for the primary reason that it is none of this WG business in general, and the OAuth specification in particular, to invent new HTTP authentication schemes. My feedback is provided in case there is overwhelming support for inclusion, to make it less damaging, if I'm instructed by the chairs to include it (and yes, I will require clear instructions from the chairs before I touch this).

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, April 14, 2011 3:47 PM
> To: Phil Hunt; Peter Saint-Andre
> Cc: oauth
> My current project uses MAC authentication for client authentication at the
> token endpoint. I would be helpful if people explicitly express their views on
> the proposed text, and whether they support or object to it.
> 
> EHL
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Apr 2011 13:47:11 +1000

I'm certainly in favour of excluding client auth from OAuth. Dropping section 3 and just having a paragraph like the following would be preferable (with no capitalized keywords):

  In many cases an authorization server will require client
  authentication for requests to a token endpoint.
  Consequently, a client app that has credentials appropriate
  for that server should proactively use them for such requests.
  The actual mechanism for client authentication, and any
  provisioning of the associated credentials, is outside
  the scope of OAuth 2.

I am not a fan of the client_id/client_secret parameters, but was resigned to their inclusion given existing deployments. Given those parameters are mentioned, OAuth2 should say:

  Various early deployments of the OAuth 2.0 concepts authenticated
  clients to the token endpoint using client_id and client_secret
  parameters in the request (alongside the grant_type parameter
  for instance). A server that accepts client_id/client_secret
  parameters MUST also accept the same credentials presented using the
  HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request
  header).

The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy (typo?). A server supporting some strong authentication mechanism must not be mandated to also support weaker BASIC and client_id/client_secret mechanisms -- and certainly not with the same secret!

"3.3 Client Assertion Credentials". OAuth2 currently supports the concept of a client app swapping an assertion for an access token. Do people want the additional functionality of using assertions for generic client authentication? I assumed servers would prefer that clients swap an assertion for a token at one specific endpoint, then use the token for generic client auth in other requests -- in which case section 3.3 "Client Assertion Credentials" can be dropped.

--
James Manger

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 14 Apr 2011 20:56:12 -0700 (PDT)

Authenticating a piece of software isn't how I view the utility of the client id and secret.  It is extremely useful for site to site authentication where a trust relationship CAN be maintained.  We really don't want to lose that functionality.

________________________________
From: "Manger, James H" <[email-masked]>
To: oauth <[email-masked]>
Sent: Thursday, April 14, 2011 8:47 PM
Subject: Re: [OAUTH-WG] Revised Section 3

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 22:13:40 -0700

The key here is that client authentication in this context is clearly HTTP authentication. This isn't about changing any functionality, but about how to be provide it. The two opposing views (generalized) are:

1. Limit section 3: the specification should simply rely on HTTP authentication and any new authentication scheme, such as the proposed client assertion credentials, be defined as new HTTP authentication schemes. There is nothing unique to client authentication in OAuth that isn't already present in other HTTP authentication schemes (and framework).

2. Expand section 3: the specification should explicitly define methods for authenticating the client using parameters instead of the HTTP authentication headers. The client password credentials reflects an existing, deployed practice, and the client assertion credentials provide an extension point desired by existing enterprise use cases.

At the end, the resolution of this issue is going to be around where to draw the line between specifying no custom client authentication to inventing 2 or more parameter-based methods, and potentially calling out specific HTTP schemes as well (e.g. Basic).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of William J. Mills
Sent: Thursday, April 14, 2011 8:56 PM
To: Manger, James H; oauth
Subject: Re: [OAUTH-WG] Revised Section 3

--
James Manger

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Apr 2011 22:14:47 -0700

I would be very happy with this approach, with the addition of discussing the role of the client identifier and that a binding to any client authentication is needed.

EHL

> Of Manger, James H
> To: oauth
> I'm certainly in favour of excluding client auth from OAuth. Dropping section
> 3 and just having a paragraph like the following would be preferable (with no
> capitalized keywords):
> 
> I am not a fan of the client_id/client_secret parameters, but was resigned to
> their inclusion given existing deployments. Given those parameters are
> mentioned, OAuth2 should say:
> 
> The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy
> (typo?). A server supporting some strong authentication mechanism must
> not be mandated to also support weaker BASIC and client_id/client_secret
> mechanisms -- and certainly not with the same secret!
> 
> "3.3 Client Assertion Credentials". OAuth2 currently supports the concept of
> a client app swapping an assertion for an access token. Do people want the
> additional functionality of using assertions for generic client authentication? I
> assumed servers would prefer that clients swap an assertion for a token at
> one specific endpoint, then use the token for generic client auth in other
> requests -- in which case section 3.3 "Client Assertion Credentials" can be
> dropped.
> 
> --
> James Manger
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 18 Apr 2011 21:53:28 +0000

>"3.3 Client Assertion Credentials". OAuth2 currently supports the concept of a client app swapping an assertion for an access token. Do people want the additional functionality of using assertions for generic client authentication? I assumed servers would >prefer that clients swap an assertion for a token at one specific endpoint, then use the token for generic client auth in other requests -- in which case section 3.3 "Client Assertion Credentials" can be dropped.

We have the case where signed assertions are used for authentication and other cases where just client_id and secrets are used. I don't agree that client assertion credentials should be dropped or that HTTP Basic Authentication can do everything that we want/need and having to go the route of suggesting a new HTTP Authentication scheme while nice does not help us with the current OAUTH that we have been developing. Removing is a breaking issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, April 14, 2011 8:47 PM
To: oauth
Subject: Re: [OAUTH-WG] Revised Section 3

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 18 Apr 2011 15:46:13 -0700

There are two separate issues here, procedural and technical. We need to address both.

Procedural issue:

The issue is how should this use case be addressed by this working group. There were always three options:

1. Not address by the WG - leaving it up to those interested to submit an individual I-D to register their extension parameters and use them as defined.
2. Address within v2 - add a section with similar functionality to the Client Assertion Credentials section present in -11.
3. Publish a companion specification - basically #1 and #2 combined, using the text from #2, published as a standalone working group document.

The *technical* end result of all three options is exactly the same. The same two parameters (or any other solution) will be defined in the same way and used the same way. The issue in picking an option from the above three is purely *political* and is about giving the solution a higher degree of endorsement. The companies interested in this work have already showed interest in other companion specification so the argument of having to point developers to multiple documents is completely without merit. Beyond that, it is nothing but perceived level of endorsement.

The benefit of going with #1 or #3 is that we can close this issue for v2 and move on without delaying the publication of the specification. Again, all three options lead to the exact same end solution and same "compliant" implementation.

I would also point out that given the extensibility model we have adopted, the authors of the proposed text could easily register the two parameters without the need to build the same level of WG consensus. Publishing a separate document is the only guaranteed method of getting the two parameters to be officially registered (no RFC is required, just a specification published somewhere which can be anywhere).

Technical issue:

As documented in my reply to this thread, there are many issues with the proposed text and solution which must be resolved before any route is taken. The biggest issue is that inventing a new HTTP authentication method based on assertions is clearly outside the scope of this working group. It is also far from established that the proposed solution is the right solution for authenticating HTTP requests using an assertion.

It doesn't matter if this is defined narrowly for use with the OAuth token endpoint because what it does in practice is invent a new HTTP authentication scheme, and doesn't even use the existing HTTP authentication framework.

The claim that "removing is a breaking issue" is patently wrong. This claim was made many times before and is baseless. A breaking change would cause current implementations using these two parameters to break. This is clearly not the case here since the v2 specification already provides a simple method for defining additional request parameters as well as client authentication methods.

EHL

> Of Anthony Nadalin
> Sent: Monday, April 18, 2011 2:53 PM
> assumed servers would >prefer that clients swap an assertion for a token at
> We have the case where signed assertions are used for authentication and
> other cases where just client_id and secrets are used. I don't agree that
> client assertion credentials should be dropped or that HTTP Basic
> Authentication can do everything that we want/need and having to go the
> route of suggesting a new HTTP Authentication scheme while nice does not
> help us with the current OAUTH that we have been developing. Removing is
> a breaking issue.
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 18 Apr 2011 22:54:54 +0000

> The claim that "removing is a breaking issue" is patently wrong. This claim was made many times before and is baseless. A breaking change would cause current implementations using these two parameters to break. This is clearly not the case here since >the v2 specification already provides a simple method for defining additional request parameters as well as client authentication methods.

It's clearly the case that we are on v10 wanting to rev our implementation and the removal is a breaking change for us. So it's not baseless as you continue to say.  I think that the text that Thomas has resurrected is just fine and I would support getting that text back into the document.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Monday, April 18, 2011 3:46 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3

Procedural issue:

Technical issue:

EHL

> a client app swapping an assertion for an access token. Do people want 
> the additional functionality of using assertions for generic client 
> authentication? I assumed servers would >prefer that clients swap an 
> assertion for a token at one specific endpoint, then use the token for 
> generic client auth in other requests -- in which case section 3.3 
> "Client Assertion Credentials" can be dropped.
> 
> We have the case where signed assertions are used for authentication 
> and other cases where just client_id and secrets are used. I don't 
> agree that client assertion credentials should be dropped or that HTTP 
> Basic Authentication can do everything that we want/need and having to 
> go the route of suggesting a new HTTP Authentication scheme while nice 
> does not help us with the current OAUTH that we have been developing. 
> Removing is a breaking issue.
> 
> 3 and just having a paragraph like the following would be preferable 
> (with no capitalized keywords):
> 
> I am not a fan of the client_id/client_secret parameters, but was 
> resigned to their inclusion given existing deployments. Given those 
> parameters are mentioned, OAuth2 should say:
> 
> The last paragraph of Thomas's "3.2 Shared Secret Credentials" is 
> crazy (typo?). A server supporting some strong authentication 
> mechanism must not be mandated to also support weaker BASIC and 
> client_id/client_secret mechanisms -- and certainly not with the same secret!
> 
> "3.3 Client Assertion Credentials". OAuth2 currently supports the 
> concept of a client app swapping an assertion for an access token. Do 
> people want the additional functionality of using assertions for 
> generic client authentication? I assumed servers would prefer that 
> clients swap an assertion for a token at one specific endpoint, then 
> use the token for generic client auth in other requests -- in which 
> case section 3.3 "Client Assertion Credentials" can be dropped.
> 
> --
> James Manger
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 18 Apr 2011 16:10:03 -0700

I don't think you understand what 'breaking' means. Breaking would be if we assigned a different meaning or syntax to the two parameters, or changed their name. Breaking requires code changes. There is nothing to prevent you from defining these parameters just like the SAML grant type did.

Was the relocation of the SAML assertion grant type to another document a "breaking" change? Clearly not according to the SAML grant type authors. The SAML specification is using the exact same extensibility framework this proposal can use. So technical issues aside, this is purely political to give this mechanism a stronger endorsement.

My objections, on the other hand, are purely technical.

As for consensus, (not wearing my editor hat) I am opposed to including that text. I have taken the time and effort to give my feedback in detail (more than once). So far no one has offered any rebuttals. I will hold off with any additional comments on this issue until the chairs decide how they want to proceed with this issue.

EHL

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Monday, April 18, 2011 3:55 PM
> To: Eran Hammer-Lahav; Manger, James H; oauth
> > The claim that "removing is a breaking issue" is patently wrong. This claim
> was made many times before and is baseless. A breaking change would
> cause current implementations using these two parameters to break. This is
> clearly not the case here since >the v2 specification already provides a simple
> method for defining additional request parameters as well as client
> authentication methods.
> 
> It's clearly the case that we are on v10 wanting to rev our implementation
> and the removal is a breaking change for us. So it's not baseless as you
> continue to say.  I think that the text that Thomas has resurrected is just fine
> and I would support getting that text back into the document.
> 
> 
> 1. Not address by the WG - leaving it up to those interested to submit an
> individual I-D to register their extension parameters and use them as
> defined.
> 2. Address within v2 - add a section with similar functionality to the Client
> Assertion Credentials section present in -11.
> 3. Publish a companion specification - basically #1 and #2 combined, using the
> text from #2, published as a standalone working group document.
> 
> The *technical* end result of all three options is exactly the same. The same
> two parameters (or any other solution) will be defined in the same way and
> used the same way. The issue in picking an option from the above three is
> purely *political* and is about giving the solution a higher degree of
> endorsement. The companies interested in this work have already showed
> interest in other companion specification so the argument of having to point
> developers to multiple documents is completely without merit. Beyond that,
> it is nothing but perceived level of endorsement.
> 
> The benefit of going with #1 or #3 is that we can close this issue for v2 and
> move on without delaying the publication of the specification. Again, all three
> options lead to the exact same end solution and same "compliant"
> implementation.
> 
> I would also point out that given the extensibility model we have adopted,
> the authors of the proposed text could easily register the two parameters
> without the need to build the same level of WG consensus. Publishing a
> separate document is the only guaranteed method of getting the two
> parameters to be officially registered (no RFC is required, just a specification
> published somewhere which can be anywhere).
> 
> Technical issue:
> 
> As documented in my reply to this thread, there are many issues with the
> proposed text and solution which must be resolved before any route is
> taken. The biggest issue is that inventing a new HTTP authentication method
> based on assertions is clearly outside the scope of this working group. It is
> also far from established that the proposed solution is the right solution for
> authenticating HTTP requests using an assertion.
> 
> It doesn't matter if this is defined narrowly for use with the OAuth token
> endpoint because what it does in practice is invent a new HTTP
> authentication scheme, and doesn't even use the existing HTTP
> authentication framework.
> 
> The claim that "removing is a breaking issue" is patently wrong. This claim was
> made many times before and is baseless. A breaking change would cause
> current implementations using these two parameters to break. This is clearly
> not the case here since the v2 specification already provides a simple method
> for defining additional request parameters as well as client authentication
> methods.
> 
> EHL
> 
> 
> > >concept of

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 18 Apr 2011 23:22:00 +0000

I'm certainly glad you gave us your definition of "breaking" but sadly your definition is not in line with ours. When a developer sits down and codes to the spec and then goes to rev the code with the latest spec and things are removed the developer now either has to drop that feature or find an additional specification that has the same feature. Can this be done in a separate specification; sure it can just like we have been creating separate specifications to make the base useable.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Monday, April 18, 2011 4:10 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3

EHL

> cause current implementations using these two parameters to break. 
> This is clearly not the case here since >the v2 specification already 
> provides a simple method for defining additional request parameters as 
> well as client authentication methods.
> 
> It's clearly the case that we are on v10 wanting to rev our 
> implementation and the removal is a breaking change for us. So it's 
> not baseless as you continue to say.  I think that the text that 
> Thomas has resurrected is just fine and I would support getting that text back into the document.
> 
> 
> 1. Not address by the WG - leaving it up to those interested to submit 
> an individual I-D to register their extension parameters and use them 
> as defined.
> 2. Address within v2 - add a section with similar functionality to the 
> Client Assertion Credentials section present in -11.
> 3. Publish a companion specification - basically #1 and #2 combined, 
> using the text from #2, published as a standalone working group document.
> 
> The *technical* end result of all three options is exactly the same. 
> The same two parameters (or any other solution) will be defined in the 
> same way and used the same way. The issue in picking an option from 
> the above three is purely *political* and is about giving the solution 
> a higher degree of endorsement. The companies interested in this work 
> have already showed interest in other companion specification so the 
> argument of having to point developers to multiple documents is 
> completely without merit. Beyond that, it is nothing but perceived level of endorsement.
> 
> The benefit of going with #1 or #3 is that we can close this issue for 
> v2 and move on without delaying the publication of the specification. 
> Again, all three options lead to the exact same end solution and same "compliant"
> implementation.
> 
> I would also point out that given the extensibility model we have 
> adopted, the authors of the proposed text could easily register the 
> two parameters without the need to build the same level of WG 
> consensus. Publishing a separate document is the only guaranteed 
> method of getting the two parameters to be officially registered (no 
> RFC is required, just a specification published somewhere which can be anywhere).
> 
> Technical issue:
> 
> As documented in my reply to this thread, there are many issues with 
> the proposed text and solution which must be resolved before any route 
> is taken. The biggest issue is that inventing a new HTTP 
> authentication method based on assertions is clearly outside the scope 
> of this working group. It is also far from established that the 
> proposed solution is the right solution for authenticating HTTP requests using an assertion.
> 
> It doesn't matter if this is defined narrowly for use with the OAuth 
> token endpoint because what it does in practice is invent a new HTTP 
> The claim that "removing is a breaking issue" is patently wrong. This 
> claim was made many times before and is baseless. A breaking change 
> would cause current implementations using these two parameters to 
> break. This is clearly not the case here since the v2 specification 
> already provides a simple method for defining additional request 
> parameters as well as client authentication methods.
> 
> EHL
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Anthony Nadalin
> > a client app swapping an assertion for an access token. Do people 
> > want the additional functionality of using assertions for generic 
> > client authentication? I assumed servers would >prefer that clients 
> > swap an assertion for a token at one specific endpoint, then use the 
> > token for generic client auth in other requests -- in which case 
> > section 3.3 "Client Assertion Credentials" can be dropped.
> >
> > agree that client assertion credentials should be dropped or that 
> > HTTP Basic Authentication can do everything that we want/need and 
> > having to go the route of suggesting a new HTTP Authentication 
> > scheme while nice does not help us with the current OAUTH that we have been developing.
> > client_id/client_secret mechanisms -- and certainly not with the 
> > same
> secret!
> >
> > concept of a client app swapping an assertion for an access token. 
> > Do people want the additional functionality of using assertions for

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 18 Apr 2011 16:24:02 -0700

At least I finally got you to agree that this can be done in a separate specification. That's progress.

EHL

> Sent: Monday, April 18, 2011 4:22 PM
> I'm certainly glad you gave us your definition of "breaking" but sadly your
> definition is not in line with ours. When a developer sits down and codes to
> the spec and then goes to rev the code with the latest spec and things are
> removed the developer now either has to drop that feature or find an
> additional specification that has the same feature. Can this be done in a
> separate specification; sure it can just like we have been creating separate
> specifications to make the base useable.
> 
> I don't think you understand what 'breaking' means. Breaking would be if we
> assigned a different meaning or syntax to the two parameters, or changed
> their name. Breaking requires code changes. There is nothing to prevent you
> from defining these parameters just like the SAML grant type did.
> 
> Was the relocation of the SAML assertion grant type to another document a
> "breaking" change? Clearly not according to the SAML grant type authors.
> The SAML specification is using the exact same extensibility framework this
> proposal can use. So technical issues aside, this is purely political to give this
> mechanism a stronger endorsement.
> 
> As for consensus, (not wearing my editor hat) I am opposed to including that
> text. I have taken the time and effort to give my feedback in detail (more
> than once). So far no one has offered any rebuttals. I will hold off with any
> additional comments on this issue until the chairs decide how they want to
> proceed with this issue.
> 
> EHL
> 
> > > Behalf Of Manger, James H

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 18 Apr 2011 23:28:52 +0000

I guess if making things complicated and dropping features and now having to go through the process of creating yet another specification is progress than maybe we are, but on the other hand looks like we are making reverse progress.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Monday, April 18, 2011 4:24 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3

EHL

> I'm certainly glad you gave us your definition of "breaking" but sadly 
> your definition is not in line with ours. When a developer sits down 
> and codes to the spec and then goes to rev the code with the latest 
> spec and things are removed the developer now either has to drop that 
> feature or find an additional specification that has the same feature. 
> Can this be done in a separate specification; sure it can just like we 
> have been creating separate specifications to make the base useable.
> 
> I don't think you understand what 'breaking' means. Breaking would be 
> if we assigned a different meaning or syntax to the two parameters, or 
> changed their name. Breaking requires code changes. There is nothing 
> to prevent you from defining these parameters just like the SAML grant type did.
> 
> Was the relocation of the SAML assertion grant type to another 
> document a "breaking" change? Clearly not according to the SAML grant type authors.
> The SAML specification is using the exact same extensibility framework 
> this proposal can use. So technical issues aside, this is purely 
> political to give this mechanism a stronger endorsement.
> 
> As for consensus, (not wearing my editor hat) I am opposed to 
> including that text. I have taken the time and effort to give my 
> feedback in detail (more than once). So far no one has offered any 
> rebuttals. I will hold off with any additional comments on this issue 
> until the chairs decide how they want to proceed with this issue.
> 
> EHL
> 
> > This is clearly not the case here since >the v2 specification 
> > Thomas has resurrected is just fine and I would support getting that 
> > text
> back into the document.
> >
> >
> > 1. Not address by the WG - leaving it up to those interested to 
> > submit an individual I-D to register their extension parameters and 
> > use them as defined.
> > 2. Address within v2 - add a section with similar functionality to 
> > the Client Assertion Credentials section present in -11.
> > The same two parameters (or any other solution) will be defined in 
> > the same way and used the same way. The issue in picking an option 
> > from the above three is purely *political* and is about giving the 
> > solution a higher degree of endorsement. The companies interested in 
> > this work have already showed interest in other companion 
> > specification so the argument of having to point developers to 
> > multiple documents is completely without merit. Beyond that, it is 
> > nothing but perceived level of
> endorsement.
> >
> > Again, all three options lead to the exact same end solution and 
> > same
> "compliant"
> > implementation.
> >
> > RFC is required, just a specification published somewhere which can 
> > be
> anywhere).
> >
> > Technical issue:
> >
> > the proposed text and solution which must be resolved before any 
> > route is taken. The biggest issue is that inventing a new HTTP 
> > authentication method based on assertions is clearly outside the 
> > scope of this working group. It is also far from established that 
> > the proposed solution is the right solution for authenticating HTTP 
> > requests
> using an assertion.
> >
> > The claim that "removing is a breaking issue" is patently wrong. 
> > This claim was made many times before and is baseless. A breaking 
> > change would cause current implementations using these two 
> > parameters to break. This is clearly not the case here since the v2 
> > specification already provides a simple method for defining 
> > additional request parameters as well as client authentication methods.
> >
> > EHL
> >
> >
> > > client authentication? I assumed servers would >prefer that 
> > > clients swap an assertion for a token at one specific endpoint, 
> > > then use the token for generic client auth in other requests -- in 
> > > which case section 3.3 "Client Assertion Credentials" can be dropped.
> > >
> > > We have the case where signed assertions are used for 
> > > authentication and other cases where just client_id and secrets 
> > > are used. I don't agree that client assertion credentials should 
> > > be dropped or that HTTP Basic Authentication can do everything 
> > > that we want/need and having to go the route of suggesting a new 
> > > HTTP Authentication scheme while nice does not help us with the 
> > > current OAUTH that we
> have been developing.
> > > 3 and just having a paragraph like the following would be 
> > > preferable (with no capitalized keywords):
> > >
> > > resigned to their inclusion given existing deployments. Given 
> > > those parameters are mentioned, OAuth2 should say:
> > >
> > > Do people want the additional functionality of using assertions 
> > > for generic client authentication? I assumed servers would prefer 
> > > that clients swap an assertion for a token at one specific 
> > > endpoint, then use the token for generic client auth in other 
> > > requests -- in which case section 3.3 "Client Assertion Credentials" can be dropped.
> > >
> > > --
> > > James Manger
> > >

---

From: Dave Nelson <[email-masked]>
Date: Tue, 19 Apr 2011 08:25:19 -0400

> The companies interested in this work have already showed interest
> in other companion specification so the argument of having to point
> developers to multiple documents is completely without merit.

I'm sorry that my first post to this list will be about IETF
etiquette, but this claim begs rebuttal.  First, in the IETF
representation is not by company, as it is in many other SDOs, but by
individual.  Second, publishing Standards Track RFCs is by IETF
Consensus, the entire IETF not just the Working Group, so such issues
are clearly not without merit.  There are times when separating issues
into multiple documents is simply a matter of organizing the workflow
of the Working Group.  Other times it's a matter of attempting to push
on with a majority view, without establishing rough consensus.  It's
the latter that is to be avoided.  It's also important to realize that
the documents produced are not simply for the consumption of those
active in their creation.  They need to be well crafted and well
organized for those who simply wish to adopt and implement the
protocol(s) they describe.  Leaving out important aspects, that will
potentially impact multi-vendor interoperability is almost always a
bad choice.

> I would also point out that given the extensibility model we have adopted.

Sorry, but IMHO this sounds a bit dismissive.

>From what I've read in this thread, I can't support that notion.  If
interoperable implementations can't be crafted without *some*
resolution to this issue, it indeed seems like a "breaking issue" to
me.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 19 Apr 2011 07:11:09 -0700

> From: Dave Nelson [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 5:25 AM

> interoperable implementations can't be crafted without *some* resolution
> to this issue, it indeed seems like a "breaking issue" to me.

This might be correct in general, but you are taking this out of the specific context of the requested change.

The proposed change does not accomplish by itself any level of interoperability since it is merely an extension point. It cannot be used without further profiling (and I have demonstrated in a previous reply why even further profiling might not produce a secure solution given the vague normative requirements provided).

IOW, in order for this proposed change to accomplish interoperability, additional specifications must be published (which also addresses some of your other concerns).

EHKL

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 19 Apr 2011 11:43:58 -0400

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, April 19, 2011 10:11 AM
> To: Dave Nelson
> Cc: oauth
> This might be correct in general, but you are taking this out of the
> specific context of the requested change.
> 
> The proposed change does not accomplish by itself any level of
> interoperability since it is merely an extension point. It cannot be
> used without further profiling (and I have demonstrated in a
previous
> reply why even further profiling might not produce a secure solution
> given the vague normative requirements provided).
> 
> IOW, in order for this proposed change to accomplish
interoperability,
> additional specifications must be published (which also addresses
some
> of your other concerns).

Hi Eran,

If its ok with you, may I offer some friendly suggestion.
Section 3 does not take away anything from your work and
enormous contribution to the Oauth 2.0 main spec.
If anything, Section 3 shows that lots of people are
interested in seeing OAuth 2.0 deployed in other environments
and being integrated into other authentication 
infrastructures (eg. enterprise infra).
I view this as a positive success point and achievement for Oauth 2.0.

And yes, further profiling & specs will be needed for each and every
type of credential mentioned in Section 3 in order to get
interoperability. That's always been my understanding (and
I believe that is also the understanding
of other folks who want Section 3 to stay).

Perhaps it would best to just leave Section 3 where it is,
and to move on to other aspects of the draft.

Thanks.

/thomas/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 19 Apr 2011 09:26:27 -0700

Hey Thomas,

> From: Thomas Hardjono [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 8:44 AM

> enormous contribution to the Oauth 2.0 main spec.

This is not a personal issue... :-)

Unlike the bearer token functionality which I consider harmful to the web and refuse to have my name associated with it, this is just a case of poorly defined functionality and the wrong way to define an HTTP authentication scheme. IOW, this one is purely about the technical qualities of the proposal. If my concerns are addressed, I don't have other external objections to the functionality.

The right example to compare this to is the discussion over the inclusion and definition of the 'scope' parameter. While much less complex, the discussion over how much to specify the 'scope' parameter is touching the same interoperability concerns.

> I view this as a positive success point and achievement for Oauth 2.0.

Yes and no.

At some point, if you extend the reach of a protocol beyond its original purpose you end up with a useless framework. I don't want to create another SOAP or WS-*.

Now, this is my personal view and I understand that in the context of an IETF standard creation every community (consumer web, enterprise, telecom, governmental, etc.) has a right to its voice. This is why I have not objected to this addition on the basis of WG scope, use cases, or requirements (which I could have easily done). My objection is purely on the technical quality of the solution.

The issue at hand is where to draw the line when it comes to defining extensibility. This is the main theme behind other open issues as well. I believe the document as currently defined provides sufficient extensibility while still providing a complete authorization protocol. This proposal merely takes that extensibility and moves it 1% forward with a tiny bit more specialization for one use case.
 
> of other folks who want Section 3 to stay).

The only way we can test if the proposal works is by doing exactly that. The same way we require multiple interoperable implementations before finish a standard, we should require at least one published draft making use of this extension point and complying with its requirements. How else would we know that we got it right?

For example, the SAML draft tested out the grant type and parameter extension point. The bearer and MAC drafts tested out the token type extension point. The UX draft tested out the error extension point (though not explicitly).

So regardless of the text being incorporated at the end, someone will need to publish a draft making use of it so that we can verify we have the right solution specified.

> and to move on to other aspects of the draft.

If you mean leave -15 section 3 as-is, I completely agree. :-)

I think your draft has some new, useful prose that I plan to incorporate either way (namely the new section about other authentication protocols). I also think that we should go back to the previous text focusing on the HTTP Basic scheme and defining the parameters alternative as just that (so as to not create a new authentication scheme, but merely document how people are "hacking" on Basic). I believe we have consensus to making those changed in -16.

Personally, I would go as far as to declare the two basic parameters as MAY support for servers and NOT RECOMMENDED for clients. But we don't have consensus for this yet (it wasn't framed this way before).

So there is value in an overall review of section 3 which your contribution has facilitated.

Since no new voices have been added to this discussion since it was originally introduced (on either side), the only next step with the new functionality (client assertion credentials) is to wait for the chairs to take over this discussion and outline how they want to gage consensus. Further discussion between the same people is pointless - no one is saying anything new, myself included.

EHL

---

From: David Recordon <[email-masked]>
Date: Tue, 19 Apr 2011 10:51:07 -0700

I think requests like this and the following discussions have scared
away many of the original voices behind OAuth 2.0. As Eran said, the
goal was never to create a new framework but standardize interoperable
best practices that the industry was adopting. Under-defined extension
points don't make this specification easier to adopt in a pragmatic
fashion.

(Obviously my individual $0.02.)

--David

---

From: Dick Hardt <[email-masked]>
Date: Tue, 19 Apr 2011 11:37:18 -0700

> points don't make this specification easier to adopt in a pragmatic

I disagree David.

While the original IETF WG charter was to standardize OAuth 1.0, we are now working on OAuth 2.0.

The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. 

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 19 Apr 2011 11:41:00 -0700

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 11:37 AM
 
> The feature described was in OAuth-WRAP which was a basis for OAuth 2.0.

Can you please point me to where this feature was in WRAP? I can't find it.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Tue, 19 Apr 2011 11:58:36 -0700

> Can you please point me to where this feature was in WRAP? I can't find it.

http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2

... or am I confused about what we are talking about changing in Section 3?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 19 Apr 2011 12:27:48 -0700

Yes, you are confused...

WRAP section 5.2 defines an assertion authorization grant type which is provided in OAuth 2.0 via two parts:

1. v2 extensible grant types [1], which provides the wrap_assertion_format parameter functionality. You simply provide a URI to identify the assertion format and include it using the grant_type parameter. No additional parameters needed.

2. SAML bearer assertion grant type document [2] which provides the wrap_assertion parameter functionality via the assertion parameter. The assertion parameter is defined in the context of the SAML extension, but is registered as a general purpose parameter and available for any future assertion grant types if they so desire.

This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11) client authentication method using assertions. It can be combined with the WRAP functionality described above to produce requests with two separate assertions (in the same request). The two functionalities has nothing to do with one another except that both use assertions as each assertions serves a completely different purpose (one for client authentication, and the other for access authorization).

Therefore, this is new functionality that was never discussed or suggested before Yaron Goland proposal was submitted and added to -11 and later removed in -12. And to prevent a broken record reply I'll add: both actions, taken by me, were done without working group consensus. So while adding and removing the section between -11 and -12 was not proper IETF editorial process, the end result is nevertheless the same - the section is out of the document pending working group consensus for inclusion.

EHL

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5
[2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03

> Sent: Tuesday, April 19, 2011 11:59 AM
> To: Eran Hammer-Lahav
> Cc: David Recordon; oauth

---

From: Dick Hardt <[email-masked]>
Date: Tue, 19 Apr 2011 13:25:15 -0700

Thanks for clarifying. Given how you have broken out Section 3 from the rest of the flow, I missed 4.5.

It is not clear in 4.5 that an access token is returned since in the previous sections, there is a separate request and response section. What is the response supposed to look like when using an access token?  Some of the confusion here may be that 4.5 is not as complete as the other sections.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 19 Apr 2011 14:00:40 -0700

So your suggestions is to add something like 4.4.3 to 4.5? That sounds like a good idea.

Would that resolve the potential confusion here?

EHL

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Tue, 19 Apr 2011 13:25:15 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Revised Section 3

-- Dick

Yes, you are confused...
-----Original Message-----
From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 11:37 AM
The feature described was in OAuth-WRAP which was a basis for OAuth
2.0.
Can you please point me to where this feature was in WRAP? I can't find it.
http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2
... or am I confused about what we are talking about changing in Section 3?

---

From: Dick Hardt <[email-masked]>
Date: Tue, 19 Apr 2011 14:06:15 -0700

Resolves *my* confusion. :)

Tony: apologies if you covered this in earlier posts, but if 4.5 does not solve your use case, would you clarify what else is needed? Are you unhappy that it is labeled an extension?

-- Dick

On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote:

> From: Dick Hardt <[email-masked]>
> To: Eran Hammer-lahav <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, oauth <[email-masked]>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 20 Apr 2011 23:05:02 +0000

So here is what I currently understand, I'm sure that I have some of this wrong;

1.       At the Prague meeting the general issue of Client Credentials removal from document was brought up, Thomas took the action item from the meeting to redraft the section that was removed. Thomas provided that. What Thomas provided is a replacement for the current section 3 in the latest draft.

2.       As Eran points out there are several parts to this issue, 1st issue is the thread going back to Yaron's text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) which was added and then removed (which were both done w/o consensus) which is authenticating with a access token request with two assertions, one from the client and one from the resource owner, the 2nd part is about authentication with id and secret and the 3rd part is about authentication with assertion.

3.       The replacement Section 3 introduces the notion client identity and authentication and provides a means to specify a client identity and secret used for authentication and also provided is a means for client authentication using assertions (such as SAML). I believe the way the replacement section 3 is worded it would solve the issue that Yaron was trying to solve and a extension could be posible.

4.       So with the current text in section 3 and section 4.5 we can't do 2 assertions since it uses grant_type=assertion. So I'm not sure that an extension based upon the current draft would help solve the problem.

So a possible issue would be if you added something like 4.4.3 to 4.5 the extension would have to conform to this, do we expect all extensions to define this in the way they want?

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 2:06 PM
To: Eran Hammer-Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

-- Dick

EHL

-- Dick

Yes, you are confused...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Apr 2011 16:52:24 -0700

I had a hard time following some of this but I’ll try to clarify.

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Wed, 20 Apr 2011 16:05:02 -0700
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>, Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] Revised Section 3

So here is what I currently understand, I’m sure that I have some of this wrong;

2.       As Eran points out there are several parts to this issue, 1st issue is the thread going back to Yaron’s text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) which was added and then removed (which were both done w/o consensus) which is authenticating with a access token request with two assertions, one from the client and one from the resource owner

This is the only requirement driving this open issue. The new proposed text does not change any other normative part of v2.

One additional note is that this doesn't mean the client has to use two assertions, but that there are two assertions and each serves a different purpose (authenticate the client, denote the resource owner authorization).

the 2nd part is about authentication with id and secret

I assume you are referring to the client password credentials section?

and the 3rd part is about authentication with assertion.

Not sure what you mean here, but if you mean authenticating a client using an assertion, that's already covered by the first part. If you mean using an assertion as the resource owner authorization, that's covered by 4.5 and the 'assertion' extension parameter.

3.       The replacement Section 3 introduces the notion client identity and authentication and provides a means to specify a client identity and secret used for authentication and also provided is a means for client authentication using assertions (such as SAML).

The replacement only adds the assertion part. The rest is already in v2. The new text includes some other useful prose, but that's purely editorial.

I believe the way the replacement section 3 is worded it would solve the issue that Yaron was trying to solve and a extension could be posible.

True, in that it bring's Yaron's proposal back practically unchanged (normative language wise).

4.       So with the current text in section 3 and section 4.5 we can’t do 2 assertions

True to the extent it doesn't specify it.

since it uses grant_type=assertion.

Nothing uses that. The 'assertion' grant type has been replaced with a more generic extension mechanism. Basically, we combined the 'grant_type' and 'assertion_type' parameters into a single extension point. So what was previously sent like this:

grant_type=assertion&assertion_type=http://some.assertion.type.uri

Is now send as:

grant_type=http://some.assertion.type.uri

This change was made in –12 with WG consensus. At the time, the 'assertion' parameter was relocated to the SAML draft.

So I’m not sure that an extension based upon the current draft would help solve the problem.

An extension grant type (which is the mechanism used by the SAML draft) will not be suitable here. This use care requires defining a new way to authentication HTTP requests (traditional client authentication) using assertions, similar to how Basic is used to authenticate requests using a username and password.

Adding 4.4.3-like text to 4.5 does not have *any* normative implications. Section 4.5 provides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding it will be done purely for clarity.

So I agree that the current specification doesn't address the use case of using an assertion to authenticate the client. Beyond that we disagree on everything else related to how to address it.

EHL

-- Dick

EHL

-- Dick

Yes, you are confused...

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 21 Apr 2011 18:34:32 +0000

Clarifications

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, April 20, 2011 4:52 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

I had a hard time following some of this but I'll try to clarify.

2.       As Eran points out there are several parts to this issue, 1st issue is the thread going back to Yaron's text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) which was added and then removed (which were both done w/o consensus) which is authenticating with a access token request with two assertions, one from the client and one from the resource owner

AJN -> Yes

AJN -> Yes section 4.5

4.       So with the current text in section 3 and section 4.5 we can't do 2 assertions

Is now send as:

This change was made in -12 with WG consensus. At the time, the 'assertion' parameter was relocated to the SAML draft.
AJN -> OK, my mistake but still causes issues

So I'm not sure that an extension based upon the current draft would help solve the problem.

An extension grant type (which is the mechanism used by the SAML draft) will not be suitable here. This use care requires defining a new way to authentication HTTP requests (traditional client authentication) using assertions, similar to how Basic is used to authenticate requests using a username and password.
AJN -> This is maybe where we differ, as taking revised section 3 solves the problem

Adding 4.4.3-like text to 4.5 does not have *any* normative implications. Section 4.5 provides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding it will be done purely for clarity.
AJN -> OK, as long as it is not normative

AJN -> Agree, and maybe we don't agree that this is a problem to be solved?

EHL

-- Dick

EHL

-- Dick

Yes, you are confused...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 21 Apr 2011 12:27:33 -0700

This got a little bit too nested so I kept only the comments where we are not on the same page.

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Thu, 21 Apr 2011 11:34:32 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>

The 'assertion' grant type has been replaced with a more generic extension mechanism. Basically, we combined the 'grant_type' and 'assertion_type' parameters into a single extension point. So what was previously sent like this:
 grant_type=assertion&assertion_type=http://some.assertion.type.uri
Is now send as:
grant_type=http://some.assertion.type.uri
This change was made in –12 with WG consensus. At the time, the 'assertion' parameter was relocated to the SAML draft.
AJN -> OK, my mistake but still causes issues
Can you please explain what issues this change causes? There is currently no open issue regarding this change, and it has nothing to do with this thread.
An extension grant type (which is the mechanism used by the SAML draft) will not be suitable here. This use care requires defining a new way to authentication HTTP requests (traditional client authentication) using assertions, similar to how Basic is used to authenticate requests using a username and password.
AJN -> This is maybe where we differ, as taking revised section 3 solves the problem
We agree here that the grant type extension mechanism does not address this use case (which was Dick's question to you). The proposed section adds a new extensibility point which does address the use case. We disagree on the details of that proposal, but we agree that it does address the use case.

Also, it doesn't matter if the new text doesn't set to define a new general purpose HTTP client authentication scheme using assertions. In practice, that's what it is creating. You can view it from the narrow perspective of the v2 specification, but in practice, deploying this client assertion credentials method means deploying a new HTTP authentication scheme.

For example, an authorization server supporting both client password credentials using HTTP Basic and this assertion alternative, will probably want to implement both at the same layer. This means that even though the assertion route does not use the HTTP authorization header, the web server will still extract those form-encoded parameter at the same place it does Basic. Otherwise you perform the same functionality (authenticating a client) at different places which for many, is not a proper architecture.

This is all philosophical about the big picture implications of what the new assertion authentication proposal does, but it is important when done in the context of an IETF standard. Much of my criticism and objections to the proposed solution and text are coming out of my view that this is not a proper way and place to define a new HTTP authentication scheme.

Since our charter is useless at this point, I have refrained from bringing up the fact that defining a new HTTP authentication scheme using assertions is out of scope. But since the chairs are now working on fixing the charter to reflect reality, I guess they will need to directly address this specific use case. Everything in –15 is implicitly in scope because it directly originates from OAuth 1.0 and WRAP. This is completely new.
Adding 4.4.3-like text to 4.5 does not have *any* normative implications. Section 4.5 provides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding it will be done purely for clarity.
AJN -> OK, as long as it is not normative
It is already normative – this is just clarifying it. Section 4.5 is an extension of the access token endpoint. All responses to the access token endpoint must comply with section 5. Adding a 4.4.3-like text merely states that. You cannot define a new grant type per 4.5 that does not comply with the normative text of section 5.

If this is a problem (which means it is a problem in –15 already), please open a new issue.
 So I agree that the current specification doesn't address the use case of using an assertion to authenticate the client. Beyond that we disagree on everything else related to how to address it.
AJN -> Agree, and maybe we don’t agree that this is a problem to be solved?
We agree it is a problem and that since you want to deploy this use case, a solution is required. I don't have anything against the use case.

However, I don't think this WG or the v2 specification are the right place to address it.

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 22 Apr 2011 21:51:33 +0000

Some additional input

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, April 21, 2011 12:28 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

AJN-> just an issue for the use case that we have as this does not allow for the usage of 2 assertions, not a new issue

Since our charter is useless at this point, I have refrained from bringing up the fact that defining a new HTTP authentication scheme using assertions is out of scope. But since the chairs are now working on fixing the charter to reflect reality, I guess they will need to directly address this specific use case. Everything in -15 is implicitly in scope because it directly originates from OAuth 1.0 and WRAP. This is completely new.

AJN-> So the client credentials originate from WRAP also, it's not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The  section 5.2 (and subsections) in the WAP specification is where you see the assertion documented but what is not explicitly stated (other than additional parameters clause)there but not disallowed is the ability to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRAP for authentication
Adding 4.4.3-like text to 4.5 does not have *any* normative implications. Section 4.5 provides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding it will be done purely for clarity.
AJN -> OK, as long as it is not normative
It is already normative - this is just clarifying it. Section 4.5 is an extension of the access token endpoint. All responses to the access token endpoint must comply with section 5. Adding a 4.4.3-like text merely states that. You cannot define a new grant type per 4.5 that does not comply with the normative text of section 5.

If this is a problem (which means it is a problem in -15 already), please open a new issue.
AJN-> I need to think on this and make sure we don't have a case where the extension would not return what is in th base
 So I agree that the current specification doesn't address the use case of using an assertion to authenticate the client. Beyond that we disagree on everything else related to how to address it.
AJN -> Agree, and maybe we don't agree that this is a problem to be solved?
We agree it is a problem and that since you want to deploy this use case, a solution is required. I don't have anything against the use case.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 22 Apr 2011 15:24:46 -0700

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Fri, 22 Apr 2011 14:51:33 -0700

AJN-> So the client credentials originate from WRAP also, it’s not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The  section 5.2 (and subsections) in the WAP specification is where you see the assertion documented but what is not explicitly stated (other than additional parameters clause)there but not disallowed is the ability to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRAP for authentication

It is completely new.

The two assertions functionality is certainly NOT in WRAP. It is not even hinted at.

Seems to me you just made my case for dropping this issue. If this is your rational for adding two assertions support in v2, then we can be done right now. v2 already gives you the exact same 'additional parameters' support and does not disallow two assertions. You have made statements in the past that WRAP did everything you needed and that v2 has to cover the same scope.

Well, it already does.

We can certainly continue to debate whether v2 needs to address this new use case, and if so how to accomplish it, but that is based solely on new requirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.0).

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 22 Apr 2011 22:34:23 +0000

I disagree here, this is not new or even completely new use case as this was in WRAP as we are using this feature now. I would agree that it's not very well documented but that was attempted by Yaron in his append was to clarify the support.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

It is completely new.

Well, it already does.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 22 Apr 2011 15:39:51 -0700

Let me make sure we're clear here:

Your argument is that this is not a new use case because WRAP allows 'additional parameters' and doesn't explicitly forbids it?

If I missed something, please quote the exact normative language in WRAP showing how to use two assertions, or any text differentiating between using an assertion for client authentication vs. using an assertion for resource owner authorization. Show me anything that pre-dates Yaron's text documenting the two assertions use case.

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Friday, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

It is completely new.

Well, it already does.

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 22 Apr 2011 22:45:25 +0000

Not sure I have to show you anything. The WRAP specification does not preclude the usage of 2 assertions as this was one of the must support use cases for WRAP. As I indicated this was not the best spelled out feature in the WRAP specification. Yaron's append was an attempt to clarify the use case with additional text. If you want to come on site you can see the code and the dates on the code that predates Yaron's text.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Friday, April 22, 2011 3:40 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

EHL

From: Anthony Nadalin [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

From: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

It is completely new.

Well, it already does.

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 22 Apr 2011 16:09:33 -0700 (PDT)

That WRAP allowed extension and that someone extended with a second assertion does not imply that a second assertion is provided for in WRAP.  It means that WRAP allowed extension.  AQre we trying to bring that extension into the main spec as a needed use case?

________________________________
From: Anthony Nadalin <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>; Dick Hardt <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Friday, April 22, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Revised Section 3

Not sure I have to show you anything. The WRAP specification does not preclude the usage of 2 assertions as this was one of the must support use cases for WRAP. As I indicated this was not the best spelled out feature in the WRAP specification. Yaron’s append was an attempt to clarify the use case with additional text. If you want to come on site you can see the code and the dates on the code that predates Yaron’s text. 
 
From:Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Friday, April 22, 2011 3:40 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3
 
Let me make sure we’re clear here:
 
Your argument is that this is not a new use case because WRAP allows ‘additional parameters’ and doesn’t explicitly forbids it?
 
If I missed something, please quote the exact normative language in WRAP showing how to use two assertions, or any text differentiating between using an assertion for client authentication vs. using an assertion for resource owner authorization. Show me anything that pre-dates Yaron’s text documenting the two assertions use case.
 
EHL

From:Anthony Nadalin [mailto:[email-masked]] 
Sent: Friday, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3
 
I disagree here, this is not new or even completely new use case as this was in WRAP as we are using this feature now. I would agree that it’s not very well documented but that was attempted by Yaron in his append was to clarify the support. 
 
From:Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

From: Anthony Nadalin <[email-masked]>
Date: Fri, 22 Apr 2011 14:51:33 -0700

It is completely new.

 
Well, it already does.

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 22 Apr 2011 23:11:59 +0000

There is no extension in WRAP to allow this, it’s allowed as part of WRAP.

From: William J. Mills [mailto:[email-masked]]
Sent: Friday, April 22, 2011 4:10 PM
To: Anthony Nadalin; Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>

EHL

It is completely new.

Well, it already does.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 22 Apr 2011 17:05:36 -0700

Yes! Exactly as it is already allowed in v2.

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Friday, April 22, 2011 4:12 PM
To: William J. Mills; Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

EHL

It is completely new.

Well, it already does.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 22 Apr 2011 17:18:18 -0700

Are you kidding me? "Not the best spelled out feature"?

It is not spelled at all. Not using a single character! Maybe Dick was using magic ink for this section.

Here are the facts:

The WRAP specification does not preclude the usage of 2 assertions. V2 does not preclude the usage of 2 assertions.
WRAP supports additional parameters. V2 supports additional parameters.

V2's support for 2 assertions is IDENTICAL to that of WRAP.

Whatever code is running at Microsoft is clearly not based on any *published* specification presented to this working group.

EHL

EHL

It is completely new.

Well, it already does.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Fri, 22 Apr 2011 18:25:29 -0700

On 2011-04-22, at 5:18 PM, Eran Hammer-Lahav wrote:

> Are you kidding me? “Not the best spelled out feature”?
>  

No magic ink was used. :)

Tony: I looked over your last emails and while I can guess what you want, a *clear* description of the flow you are looking for would enable me to bridge the gap between WRAP and OAuth 2.0.

-- Dick