Subject: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

From: Phil Hunt <[email-masked]>
Date: Mon, 29 Jul 2013 10:14:16 +0200

FYI.  I have been noticing a substantial number of sites acting as OAuth Clients using OAuth to authenticate users.

I know several of us have blogged on the issue over the past year so I won't re-hash it here.  In short, many of us recommended OIDC as the correct methodology.

Never-the-less, I've spoken with a number of service providers who indicate they are not ready to make the jump to OIDC, yet they agree there is a desire to support authentication only (where as OIDC does IDP-like services).

This draft is intended as a minimum authentication only specification.  I've tried to make it as compatible as possible with OIDC.

For now, I've just posted to keep track of the issue so we can address at the next re-chartering.

Happy to answer questions and discuss. 

Phil

@independentid
www.independentid.com
[email-masked]

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
> Date: 29 July, 2013 9:49:41 AM GMT+02:00
> To: Phil Hunt <[email-masked]>, Phil Hunt <[email-masked]>, Phil Hunt <>
> 
> 
> A new version of I-D, draft-hunt-oauth-v2-user-a4c-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Filename:	 draft-hunt-oauth-v2-user-a4c
> Revision:	 00
> Title:		 OAuth 2.0 User Authentication For Client
> Creation date:	 2013-07-29
> Group:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
> Htmlized:        http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00
> 
> 
> Abstract:
>   This specification defines a new OAuth2 endpoint that enables user
>   authentication session information to be shared with client
>   applications.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 30 Jul 2013 07:58:18 +0000

So is the intent to provide an enterprise authentication claim? I would think that the proposal would use JWT as the token and then define the appropriate claim in the JWT

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, July 29, 2013 1:14 AM
To: [email-masked] WG
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
Date: 29 July, 2013 9:49:41 AM GMT+02:00
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>, Phil Hunt <>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 30 Jul 2013 14:46:26 +0000

>From what I read, you've defined something that uses an OAuth 2 code flow to get an extra token which is specified as a JWT. You named it "session_token" instead of "id_token", and you've left off the User Information Endpoint -- but other than that, this is exactly the Basic Client for OpenID Connect. In other words, if you change the names on things you've got OIDC, but without the capabilities to go beyond a very basic "hey there's a user here" claim. This is the same place that OpenID 2.0 started, and it was very, very quickly extended with SREG, AX, PAPE, and others for it to be useful in the real world of distributed logins. You've also left out discovery and registration which are required for distributed deployments, but I'm guessing that those would be modular components that could be added in (like they are in OIDC).

I've heard complaints that OIDC is complicated, but it's really not. Yes, I agree that the giant stack of documents is intimidating and in my opinion it's a bit of a mess with Messages and Standard split up (but I lost that argument years ago). However, at the core, you've got an OAuth2 authorization server that spits out access tokens and id tokens. The id token is a JWT with some known claims (iss, sub, etc) and is issued along side the access token, and its audience is the *client* and not the *protected resource*. The access token is a regular old access token and its format is undefined (so you can use it with an existing OAuth2 server setup, like we have), and it can be used at the User Info Endpoint to get profile information about the user who authenticated. It could also be used for other services if your AS/IdP protects multiple things.

So I guess what I'm missing is what's the value proposition in this spec when we have something that can do this already? And this doesn't seem to do anything different (apart from syntax changes)?

 -- Justin

On Jul 29, 2013, at 4:14 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

Begin forwarded message:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 30 Jul 2013 16:54:42 +0200

The oidc specs do not allow this simple an implementation. The spec members have not shown interest in making changes as they say they are too far down the road.

I have tried to make my draft as close as possible to oidc but maybe it shouldn't be clarity wise. I am interested in what the group feels is clearest. 

From an ietf perspective the concern is improper use of the 6749 for authn. Is this a bug or gap we need to address?

Phil

On 2013-07-30, at 16:46, "Richer, Justin P." <[email-masked]> wrote:

> On Jul 29, 2013, at 4:14 AM, Phil Hunt <[email-masked]> wrote:
> 
>> [email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 30 Jul 2013 15:17:46 +0000

What do you mean? You absolutely can implement a compliant OIDC server nearly as simply as this. The things that you're missing I think are necessary for basic interoperable functionality, and are things that other folks using OAuth for authentication have also implemented. Namely:

 - Signing the ID token (OIDC specifies the RS256 flavor of JWS, which is easy to do with JWT). Without a signed and verifiable ID token or equivalent, you're asking for all kinds of token injection problems.
 - Session management requests (max auth age, auth time)
 - Not fall over with other parameters that you don't support (display, prompt, etc).

See here for more information:

  http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI

Additionally, something that's really important to support is the User Info Endpoint, so you can actually get user profile information beyond just the simple "someone was here" claim -- this was the real value of Facebook Connect from an RP's perspective. Some people will probably want to use SCIM for this, too, and that's fine.

 -- Justin

On Jul 30, 2013, at 10:54 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>>
 wrote:

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Phil Hunt <[email-masked]>
Date: Tue, 30 Jul 2013 17:30:08 +0200

Forgot reply all.

Phil

Begin forwarded message:

> From: Phil Hunt <[email-masked]>
> Date: 30 July, 2013 17:25:46 GMT+02:00
> To: "Richer, Justin P." <[email-masked]>
> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
> 
> The whole point is authn only. Many do not want or need the userinfo endpoint. 
> 
> Phil
> 
> On 2013-07-30, at 17:17, "Richer, Justin P." <[email-masked]> wrote:
> 
>> On Jul 30, 2013, at 10:54 AM, Phil Hunt <[email-masked]>
>>  wrote:
>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 30 Jul 2013 15:30:51 +0000

That's what people thought with OpenID 2.0, and they were wrong then, too, if you ask me. Even then, userinfo endpoint isn't MTI anyway.

 -- Justin

On Jul 30, 2013, at 11:25 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>>
 wrote:

Phil

On 2013-07-30, at 17:17, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: John Bradley <[email-masked]>
Date: Tue, 30 Jul 2013 17:47:59 +0200

Connect dosen't require a userinfo endpoint.   It is required for interoperability if you are building an open IdP.   For an enterprise type deployment discovery, registration, userifo are all optional.

The server is required to pass the nonce which is equivalent to a request ID through to the JWT if the client sends it in the request.

Justin is correct.

John B.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 31 Jul 2013 01:27:32 +0900

I have written a short blog post titled "Write an OpenID Connect server in
three simple steps<http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/>
".

Really, there is not much you need to on top of OAuth 2.0.

It puzzles me why you need to create a draft with only minor variances in
parameter names.

e.g.,
session instead of id_token
lat instead of iat
alv instead of acr
etc.

If you change those parameter names, you will have a conformant profile of
OpenID Connect.

Nat

2013/7/31 John Bradley <[email-masked]>

> Connect dosen't require a userinfo endpoint.   It is required for
> interoperability if you are building an open IdP.   For an enterprise type
> deployment discovery, registration, userifo are all optional.
>
> The server is required to pass the nonce which is equivalent to a request
> ID through to the JWT if the client sends it in the request.
>
> Justin is correct.
>
> John B.
>
> *From:* Phil Hunt <[email-masked]>
> *Date:* 30 July, 2013 17:25:46 GMT+02:00
> *To:* "Richer, Justin P." <[email-masked]>
> *Subject:* *Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-00.txt*
>
> What do you mean? You absolutely can implement a compliant OIDC server
> nearly as simply as this. The things that you're missing I think are
> necessary for basic interoperable functionality, and are things that other
> folks using OAuth for authentication have also implemented. Namely:
>
>   - Signing the ID token (OIDC specifies the RS256 flavor of JWS, which
> is easy to do with JWT). Without a signed and verifiable ID token or
> equivalent, you're asking for all kinds of token injection problems.
>  Additionally, something that's really important to support is the User
> Info Endpoint, so you can actually get user profile information beyond just
> the simple "someone was here" claim -- this was the real value of Facebook
> Connect from an RP's perspective. Some people will probably want to use
> SCIM for this, too, and that's fine.
>
>   -- Justin
>
>  The oidc specs do not allow this simple an implementation. The spec
> members have not shown interest in making changes as they say they are too
> far down the road.
>
>  I have tried to make my draft as close as possible to oidc but maybe it
> shouldn't be clarity wise. I am interested in what the group feels is
> clearest.
>
>  From an ietf perspective the concern is improper use of the 6749 for
> authn. Is this a bug or gap we need to address?
>
> Phil
>
>  From what I read, you've defined something that uses an OAuth 2 code
> flow to get an extra token which is specified as a JWT. You named it
> "session_token" instead of "id_token", and you've left off the User
> Information Endpoint -- but other than that, this is exactly the Basic
> Client for OpenID Connect. In other words, if you change the names on
> things you've got OIDC, but without the capabilities to go beyond a very
> basic "hey there's a user here" claim. This is the same place that OpenID
> 2.0 started, and it was very, very quickly extended with SREG, AX, PAPE,
> and others for it to be useful in the real world of distributed logins.
> You've also left out discovery and registration which are required for
> distributed deployments, but I'm guessing that those would be modular
> components that could be added in (like they are in OIDC).
>
>  I've heard complaints that OIDC is complicated, but it's really not.
> Yes, I agree that the giant stack of documents is intimidating and in my
> opinion it's a bit of a mess with Messages and Standard split up (but I
> lost that argument years ago). However, at the core, you've got an OAuth2
> authorization server that spits out access tokens and id tokens. The id
> token is a JWT with some known claims (iss, sub, etc) and is issued along
> side the access token, and its audience is the *client* and not the
> *protected resource*. The access token is a regular old access token and
> its format is undefined (so you can use it with an existing OAuth2 server
> setup, like we have), and it can be used at the User Info Endpoint to get
> profile information about the user who authenticated. It could also be used
> for other services if your AS/IdP protects multiple things.
>
>  So I guess what I'm missing is what's the value proposition in this spec
> when we have something that can do this already? And this doesn't seem to
> do anything different (apart from syntax changes)?
>
>   -- Justin
>
>  FYI.  I have been noticing a substantial number of sites acting as OAuth
> Clients using OAuth to authenticate users.
>
>  I know several of us have blogged on the issue over the past year so I
> won't re-hash it here.  In short, many of us recommended OIDC as the
> correct methodology.
>
>  Never-the-less, I've spoken with a number of service providers who
> indicate they are not ready to make the jump to OIDC, yet they agree there
> is a desire to support authentication only (where as OIDC does IDP-like
> services).
>
>  This draft is intended as a minimum authentication only specification.
>  I've tried to make it as compatible as possible with OIDC.
>
>  *From: [email-masked]
>  *Subject: **New Version Notification for
> draft-hunt-oauth-v2-user-a4c-00.txt*
>  *Date: *29 July, 2013 9:49:41 AM GMT+02:00
>  *To: *Phil Hunt <[email-masked]>, Phil Hunt <[email-masked]>,
> Phil Hunt <>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
> Htmlized:
> http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00
>
>
> Abstract:

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Brian Campbell <[email-masked]>
Date: Tue, 30 Jul 2013 18:39:44 +0200

Yes, that.

On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. <[email-masked]>wrote:

> lost that argument years ago).
>

---

From: Paul Madsen <[email-masked]>
Date: Tue, 30 Jul 2013 12:57:36 -0400

I always think I pretty much understand OIDC until I see the specs list

On 7/30/13 12:39 PM, Brian Campbell wrote:
> Yes, that.
>
> On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Yes, I agree that the giant stack of documents is intimidating and
>     in my opinion it's a bit of a mess with Messages and Standard
>     split up (but I lost that argument years ago).
>
>
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 30 Jul 2013 17:01:55 +0000

So it's not the protocol that's the problem, it's the documentation. For that I'm 100% with you all. However, I really don't think that the right response to that is "we'll just invent something new and incompatible with slightly different names" -- it's to document the protocol better.

 -- Justin

On Jul 30, 2013, at 12:57 PM, Paul Madsen <[email-masked]<mailto:[email-masked]>>
 wrote:

On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:

Yes, I agree that the giant stack of documents is intimidating and in my opinion it's a bit of a mess with Messages and Standard split up (but I lost that argument years ago).

---

From: Todd W Lainhart <[email-masked]>
Date: Tue, 30 Jul 2013 14:11:14 -0400

> I always think I pretty much understand OIDC until I see the specs list

It's not just me, then.

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Paul Madsen <[email-masked]>
To:     Brian Campbell <[email-masked]>, 
Cc:     "[email-masked] WG" <[email-masked]>
Date:   07/30/2013 12:59 PM
Subject:        Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-00.txt
Sent by:        [email-masked]

On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. <[email-masked]> 
wrote:

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 31 Jul 2013 05:43:10 +0900

Right. Anyone who agreed to IPR could have proposed the text in the work
group.

Re: Messages and Standard

Messages were supposed to be the collection of terminology and parameters
sets.
Standard was meant to be HTTP binding, which would effectively make it
OAuth 2.0 + authentication + identity.
As such, normative portion of the standard was to be made of the HTTP
protocol element, reference to the parameters sets in Messages, and the
documentation on how to serialize. It should be very concise. Non-normative
portions were supposed to have examples. In some sections, it is like that,
but in sections like 2.2.1.1, it is currently repeating much of what the
Messages have.
This, to me, is suboptimal but many people wanted to be this way so that
they do not have to refer to the Messages.

Maybe, for the final, we might reconsider it.

2013/7/31 Richer, Justin P. <[email-masked]>

>  So it's not the protocol that's the problem, it's the documentation. For
> that I'm 100% with you all. However, I really don't think that the right
> response to that is "we'll just invent something new and incompatible with
> slightly different names" -- it's to document the protocol better.
>
>   -- Justin
>
>  On Jul 30, 2013, at 12:57 PM, Paul Madsen <[email-masked]>
>  wrote:
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>

---

From: Prateek Mishra <[email-masked]>
Date: Tue, 30 Jul 2013 18:32:23 -0400

Nat -

your blog posting is helpful to those of us who are looking for a 
minimal extension of OAuth with
an authenticator.  Many implementors are seeking a modest extension of 
OAuth, not an entire new protocol
stack.   I believe that is the point of Phil Hunt's proposal to the 
OAuth committee.

I do have some questions for about the statements made in the blog -

A) Can you direct me to a single OpenID Connect draft specification 
document where steps 1 and 2 are described?

B) If I implement steps 1 and 2, do I then have a conformant OpenID 
Connect implementation? Are there no
other MTI protocol exchanges in OpenID Connect?

Thanks,
prateek

> I have written a short blog post titled "Write an OpenID Connect 
> server in three simple steps 
> <http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/>". 
>
>
> It puzzles me why you need to create a draft with only minor variances 
> in parameter names.
>
>     e.g.,
> If you change those parameter names, you will have a conformant 
> profile of OpenID Connect.
>
> Nat
>
>
> 2013/7/31 John Bradley <[email-masked] <mailto:[email-masked]>>
>
>     interoperability if you are building an open IdP.   For an
>     enterprise type deployment discovery, registration, userifo are
>     all optional.
>
>     The server is required to pass the nonce which is equivalent to a
>     request ID through to the JWT if the client sends it in the request.
>
>     Justin is correct.
>
>     John B.
>
>     On 2013-07-30, at 5:30 PM, Phil Hunt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     Forgot reply all.
>>
>>     Phil
>>
>>     Begin forwarded message:
>>
>>>     *From:* Phil Hunt <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *To:* "Richer, Justin P." <[email-masked]
>>>     <mailto:[email-masked]>>
>>>>     What do you mean? You absolutely can implement a compliant OIDC
>>>>     server nearly as simply as this. The things that you're missing
>>>>     I think are necessary for basic interoperable functionality,
>>>>     and are things that other folks using OAuth for authentication
>>>>     have also implemented. Namely:
>>>>
>>>>      - Signing the ID token (OIDC specifies the RS256 flavor of
>>>>     JWS, which is easy to do with JWT). Without a signed and
>>>>     verifiable ID token or equivalent, you're asking for all kinds
>>>>     of token injection problems.
>>>>     Additionally, something that's really important to support is
>>>>     the User Info Endpoint, so you can actually get user profile
>>>>     information beyond just the simple "someone was here" claim --
>>>>     this was the real value of Facebook Connect from an RP's
>>>>     perspective. Some people will probably want to use SCIM for
>>>>     this, too, and that's fine.
>>>>
>>>>      -- Justin
>>>>
>>>>>     The oidc specs do not allow this simple an implementation. The
>>>>>     spec members have not shown interest in making changes as they
>>>>>     say they are too far down the road.
>>>>>
>>>>>     I have tried to make my draft as close as possible to oidc but
>>>>>     maybe it shouldn't be clarity wise. I am interested in what
>>>>>     the group feels is clearest.
>>>>>
>>>>>     From an ietf perspective the concern is improper use of the
>>>>>     6749 for authn. Is this a bug or gap we need to address?
>>>>>
>>>>>     Phil
>>>>>
>>>>>     On 2013-07-30, at 16:46, "Richer, Justin P."
>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>>>     From what I read, you've defined something that uses an OAuth
>>>>>>     2 code flow to get an extra token which is specified as a
>>>>>>     JWT. You named it "session_token" instead of "id_token", and
>>>>>>     you've left off the User Information Endpoint -- but other
>>>>>>     than that, this is exactly the Basic Client for OpenID
>>>>>>     Connect. In other words, if you change the names on things
>>>>>>     you've got OIDC, but without the capabilities to go beyond a
>>>>>>     very basic "hey there's a user here" claim. This is the same
>>>>>>     place that OpenID 2.0 started, and it was very, very quickly
>>>>>>     extended with SREG, AX, PAPE, and others for it to be useful
>>>>>>     in the real world of distributed logins. You've also left out
>>>>>>     discovery and registration which are required for distributed
>>>>>>     deployments, but I'm guessing that those would be modular
>>>>>>     I've heard complaints that OIDC is complicated, but it's
>>>>>>     really not. Yes, I agree that the giant stack of documents is
>>>>>>     intimidating and in my opinion it's a bit of a mess with
>>>>>>     Messages and Standard split up (but I lost that argument
>>>>>>     years ago). However, at the core, you've got an OAuth2
>>>>>>     authorization server that spits out access tokens and id
>>>>>>     tokens. The id token is a JWT with some known claims (iss,
>>>>>>     sub, etc) and is issued along side the access token, and its
>>>>>>     audience is the *client* and not the *protected resource*.
>>>>>>     The access token is a regular old access token and its format
>>>>>>     is undefined (so you can use it with an existing OAuth2
>>>>>>     server setup, like we have), and it can be used at the User
>>>>>>     Info Endpoint to get profile information about the user who
>>>>>>     authenticated. It could also be used for other services if
>>>>>>     your AS/IdP protects multiple things.
>>>>>>
>>>>>>     So I guess what I'm missing is what's the value proposition
>>>>>>     in this spec when we have something that can do this already?
>>>>>>     And this doesn't seem to do anything different (apart from
>>>>>>     syntax changes)?
>>>>>>
>>>>>>      -- Justin
>>>>>>
>>>>>>>     FYI.  I have been noticing a substantial number of sites
>>>>>>>     acting as OAuth Clients using OAuth to authenticate users.
>>>>>>>
>>>>>>>     I know several of us have blogged on the issue over the past
>>>>>>>     year so I won't re-hash it here.  In short, many of us
>>>>>>>     recommended OIDC as the correct methodology.
>>>>>>>
>>>>>>>     Never-the-less, I've spoken with a number of service
>>>>>>>     providers who indicate they are not ready to make the jump
>>>>>>>     to OIDC, yet they agree there is a desire to support
>>>>>>>     authentication only (where as OIDC does IDP-like services).
>>>>>>>
>>>>>>>     This draft is intended as a minimum authentication only
>>>>>>>     specification.  I've tried to make it as compatible as
>>>>>>>     possible with OIDC.
>>>>>>>
>>>>>>>     www.independentid.com <http://www.independentid.com/>
>>>>>>>     [email-masked] <mailto:[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     Begin forwarded message:
>>>>>>>
>>>>>>>>     <mailto:[email-masked]>
>>>>>>>>     *To: *Phil Hunt <[email-masked]
>>>>>>>>     <mailto:[email-masked]>>, Phil Hunt
>>>>>>>>     <[email-masked] <mailto:[email-masked]>>, Phil
>>>>>>>>     Hunt <>
>>>>>>>>
>>>>>>>>
>>>>>>>>     Filename:draft-hunt-oauth-v2-user-a4c
>>>>>>>>     Revision:00
>>>>>>>>     Title:OAuth 2.0 User Authentication For Client
>>>>>>>>     Creation date:2013-07-29
>>>>>>>>     Group:Individual Submission
>>>>>>>>     Number of pages: 9
>>>>>>>>     URL:
>>>>>>>>     until the htmlized version and diff are available at
>>>>>>>>     tools.ietf.org <http://tools.ietf.org/>.
>>>>>>>>
>>>>>>>>     The IETF Secretariat
>>>>>>>>
>>>>>>>
>>>>>>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 31 Jul 2013 09:09:16 +0900

Inline:

2013/7/31 Prateek Mishra <[email-masked]>

>  Nat -
>
> your blog posting is helpful to those of us who are looking for a minimal
> extension of OAuth with
> stack.   I believe that is the point of Phil Hunt's proposal to the OAuth
> committee.
>

Actually, it is not a single spec, that the Standard is referencing others.
The Standard is kind of cluttered because it has 6 response types and three
request types in it.
I suppose it would be much easier for the readers to split them into
coherent pieces, though that means duplicate texts.

The easiest approach here is to read the Basic Client Profile.
http://openid.net/specs/openid-connect-basic-1_0-28.html
Then, read OAuth 2.0 Multiple Response Type Encoding Practices
http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html .

> other MTI protocol exchanges in OpenID Connect?

Yes, for a non-dynamic OpenID Connect Server.

Nat

>
> Thanks,
> prateek
>
>
>
>
>  I have written a short blog post titled "Write an OpenID Connect server
> in three simple steps<http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/>".
>
>
>  If you change those parameter names, you will have a conformant profile
> of OpenID Connect.
>
>  Nat
>
>
>>  So I guess what I'm missing is what's the value proposition in this
>> spec when we have something that can do this already? And this doesn't seem
>> to do anything different (apart from syntax changes)?
>>
>>   -- Justin
>>
>>  FYI.  I have been noticing a substantial number of sites acting as
>> OAuth Clients using OAuth to authenticate users.
>>

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 31 Jul 2013 17:38:43 -0400

Nat -

thanks for the detailed response. I did review the links you sent out 
but it remained unclear to me which
features are MTI and which are not. For example, there is nothing in the 
Basic Client Profile that suggests
that Section 2.3 is optional. I also could not find any definition for " 
non-dynamic OpenID Connect Server".

I dont think there is a need to duplicate portions of the draft 
specification text in a new document. One solution
that was used in SAML 2.0 was to define a conformance document which 
described several different
operational modes and explained how only a small set of features needed 
to be implemented in certain modes.

http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf

There are probably other smarter ways to achieve the same effect.

Given this situation, I do think its a reasonable task for the OAuth 
community to consider the need for
a minimal extension to OAuth that accommodates authentication. The 
community should be made aware that
RFC 6749 is being misused for federated authentication, as explained in  -

http://www.independentid.com/2013/07/simple-authentication-for-oauth-2-what.html 

and that there doesn't appear to be a simple solution that is currently 
available. It would be great if it turned
out that OpenID Connect offered such a solution but that isn't clear to me.

Thx,
prateek

>
> Inline:
>
> 2013/7/31 Prateek Mishra <[email-masked] 
> <mailto:[email-masked]>>
>
>     Nat -
>
>     an authenticator.  Many implementors are seeking a modest
>     extension of OAuth, not an entire new protocol
>     stack.   I believe that is the point of Phil Hunt's proposal to
>     the OAuth committee.
>
>     A) Can you direct me to a single OpenID Connect draft
>     specification document where steps 1 and 2 are described?
>
>
> The Standard is kind of cluttered because it has 6 response types and 
> three request types in it.
>     B) If I implement steps 1 and 2, do I then have a conformant
>     OpenID Connect implementation? Are there no
>>     It puzzles me why you need to create a draft with only minor
>>     variances in parameter names.
>>
>>         e.g.,
>>         Connect dosen't require a userinfo endpoint.   It is required
>>         for interoperability if you are building an open IdP.   For
>>         an enterprise type deployment discovery, registration,
>>         userifo are all optional.
>>
>>         The server is required to pass the nonce which is equivalent
>>         to a request ID through to the JWT if the client sends it in
>>         the request.
>>
>>         Justin is correct.
>>
>>         John B.
>>
>>>>         On 2013-07-30, at 17:17, "Richer, Justin P."
>>>>>         What do you mean? You absolutely can implement a compliant
>>>>>         OIDC server nearly as simply as this. The things that
>>>>>         you're missing I think are necessary for basic
>>>>>         interoperable functionality, and are things that other
>>>>>          - Signing the ID token (OIDC specifies the RS256 flavor
>>>>>         of JWS, which is easy to do with JWT). Without a signed
>>>>>         and verifiable ID token or equivalent, you're asking for
>>>>>         all kinds of token injection problems.
>>>>>         Additionally, something that's really important to support
>>>>>         is the User Info Endpoint, so you can actually get user
>>>>>         profile information beyond just the simple "someone was
>>>>>         here" claim -- this was the real value of Facebook Connect
>>>>>         from an RP's perspective. Some people will probably want
>>>>>         to use SCIM for this, too, and that's fine.
>>>>>
>>>>>          -- Justin
>>>>>
>>>>>         On Jul 30, 2013, at 10:54 AM, Phil Hunt
>>>>>         <[email-masked] <mailto:[email-masked]>>
>>>>>          wrote:
>>>>>
>>>>>>         The oidc specs do not allow this simple an
>>>>>>         implementation. The spec members have not shown interest
>>>>>>         in making changes as they say they are too far down the road.
>>>>>>
>>>>>>         I have tried to make my draft as close as possible to
>>>>>>         oidc but maybe it shouldn't be clarity wise. I am
>>>>>>         interested in what the group feels is clearest.
>>>>>>
>>>>>>         From an ietf perspective the concern is improper use of
>>>>>>         the 6749 for authn. Is this a bug or gap we need to address?
>>>>>>
>>>>>>         Phil
>>>>>>
>>>>>>>         From what I read, you've defined something that uses an
>>>>>>>         OAuth 2 code flow to get an extra token which is
>>>>>>>         specified as a JWT. You named it "session_token" instead
>>>>>>>         of "id_token", and you've left off the User Information
>>>>>>>         Endpoint -- but other than that, this is exactly the
>>>>>>>         Basic Client for OpenID Connect. In other words, if you
>>>>>>>         change the names on things you've got OIDC, but without
>>>>>>>         the capabilities to go beyond a very basic "hey there's
>>>>>>>         a user here" claim. This is the same place that OpenID
>>>>>>>         2.0 started, and it was very, very quickly extended with
>>>>>>>         SREG, AX, PAPE, and others for it to be useful in the
>>>>>>>         real world of distributed logins. You've also left out
>>>>>>>         discovery and registration which are required for
>>>>>>>         distributed deployments, but I'm guessing that those
>>>>>>>         would be modular components that could be added in (like
>>>>>>>         they are in OIDC).
>>>>>>>
>>>>>>>         really not. Yes, I agree that the giant stack of
>>>>>>>         documents is intimidating and in my opinion it's a bit
>>>>>>>         of a mess with Messages and Standard split up (but I
>>>>>>>         lost that argument years ago). However, at the core,
>>>>>>>         you've got an OAuth2 authorization server that spits out
>>>>>>>         access tokens and id tokens. The id token is a JWT with
>>>>>>>         some known claims (iss, sub, etc) and is issued along
>>>>>>>         side the access token, and its audience is the *client*
>>>>>>>         and not the *protected resource*. The access token is a
>>>>>>>         regular old access token and its format is undefined (so
>>>>>>>         you can use it with an existing OAuth2 server setup,
>>>>>>>         like we have), and it can be used at the User Info
>>>>>>>         Endpoint to get profile information about the user who
>>>>>>>         authenticated. It could also be used for other services
>>>>>>>         if your AS/IdP protects multiple things.
>>>>>>>
>>>>>>>         So I guess what I'm missing is what's the value
>>>>>>>         proposition in this spec when we have something that can
>>>>>>>         do this already? And this doesn't seem to do anything
>>>>>>>         different (apart from syntax changes)?
>>>>>>>
>>>>>>>          -- Justin
>>>>>>>
>>>>>>>         On Jul 29, 2013, at 4:14 AM, Phil Hunt
>>>>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>>         FYI.  I have been noticing a substantial number of
>>>>>>>>         sites acting as OAuth Clients using OAuth to
>>>>>>>>         authenticate users.
>>>>>>>>
>>>>>>>>         I know several of us have blogged on the issue over the
>>>>>>>>         past year so I won't re-hash it here.  In short, many
>>>>>>>>         of us recommended OIDC as the correct methodology.
>>>>>>>>
>>>>>>>>         providers who indicate they are not ready to make the
>>>>>>>>         jump to OIDC, yet they agree there is a desire to
>>>>>>>>         support authentication only (where as OIDC does
>>>>>>>>         IDP-like services).
>>>>>>>>
>>>>>>>>         For now, I've just posted to keep track of the issue so
>>>>>>>>         we can address at the next re-chartering.
>>>>>>>>
>>>>>>>>>         <[email-masked] <mailto:[email-masked]>>,
>>>>>>>>>         Phil Hunt <>
>>>>>>>>>
>>>>>>>>>

---

From: Bill Mills <[email-masked]>
Date: Wed, 31 Jul 2013 14:49:35 -0700 (PDT)

Rather than extending OAuth for something OpenID already does...  why don't we get a simple informational example doc to show how to implement the most basic OpenID service, which is the same functionality on a standard that's already written?

This is sounding more and mor elike a documentation problem.

________________________________
 From: Prateek Mishra <[email-masked]>
To: Nat Sakimura <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]> 
Sent: Wednesday, July 31, 2013 2:38 PM
Subject: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)

Nat - 

thanks for the detailed response. I did review the links you sent
    out but it remained unclear to me which
features are MTI and which are not. For example, there is nothing in
    the Basic Client Profile that suggests
that Section 2.3 is optional. I also could not find any definition
    for " non-dynamic OpenID Connect Server".

I dont think there is a need to duplicate portions of the draft
    specification text in a new document. One solution
that was used in SAML 2.0 was to define a conformance document which
    described several different 
operational modes and explained how only a small set of features
    needed to be implemented in certain modes.

RFC 6749 is being misused for federated authentication, as explained
    in  -  

and that there doesn't appear to be a simple solution that is
    currently available. It would be great if it turned
out that OpenID Connect offered such a solution but that isn't clear
    to me.

Thx,
prateek

>>your blog posting is helpful to those of us who are
                looking for a minimal extension of OAuth with 
>>an authenticator.  Many implementors are seeking a
                modest extension of OAuth, not an entire new protocol
>>stack.   I believe that is the point of Phil Hunt's
                proposal to the OAuth committee.
>>A) Can you direct me to a single OpenID Connect draft
                specification document where steps 1 and 2 are
                described?
>The Standard is kind of cluttered because it has 6 response types and three request types in it. 
>I suppose it would be much easier for the readers to split them into coherent pieces, though that means duplicate texts. 
>
>
>The easiest approach here is to read the Basic Client Profile. http://openid.net/specs/openid-connect-basic-1_0-28.html
>Then, read OAuth 2.0 Multiple Response Type Encoding Practices http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html . 
>
>
>
>>B) If I implement steps 1 and 2, do I then have a
                conformant OpenID Connect implementation? Are there no 
>>I have written a short blog post titled "Write an OpenID Connect server in three simple steps".  
>>>
>>>
>>>It puzzles me why you need to create a draft with only minor variances in parameter names. 
>>>
>>>
>>>e.g., 
>>>If you change those parameter names, you will have a conformant profile of OpenID Connect. 
>>>
>>>
>>>Nat
>>>
>>>
>>>
>>>>>>On 2013-07-30, at 17:17,
                                              "Richer, Justin P." <[email-masked]> wrote:
>>>>>>>>On 2013-07-30,
                                                        at 16:46,
                                                        "Richer, Justin
                                                        P." <[email-masked]> wrote:
>>>>>>>>>>[email-masked]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Begin forwarded message:
>>>>>>>>>>
>>>>>>>>>>>A new version
                                                          of I-D,
>>>>>>>>>>>has been
                                                          successfully
                                                          submitted by
                                                          Phil Hunt and
                                                          posted to the
>>>>>>>>>>>IETF
                                                          repository.
>>>>>>>>>>>Number of
                                                          pages: 9
>>>>>>>>>>>  This
                                                          specification
                                                          defines a new
                                                          OAuth2
                                                          endpoint that
                                                          enables user
>>>>>>>>>>>  authentication

                                                          session
                                                          information to
                                                          be shared with
                                                          client
>>>>>>>>>>>Please note
                                                          that it may
                                                          take a couple
                                                          of minutes
                                                          from the time
                                                          of submission
>>>>>>>>>>>until the
                                                          htmlized
                                                          version and
                                                          diff are
                                                          available at tools.ietf.org.
>>>>>>>>>>>The IETF
                                                          Secretariat
>>>>>>>>>>OAuth mailing
                                                          list
-- 
>>>Chairman, OpenID Foundation
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 
--

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 1 Aug 2013 00:51:28 +0000

+1

On Jul 31, 2013, at 5:49 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Prateek Mishra <[email-masked]<mailto:[email-masked]>>
To: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 31, 2013 2:38 PM
Subject: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)

Nat -

thanks for the detailed response. I did review the links you sent out but it remained unclear to me which
features are MTI and which are not. For example, there is nothing in the Basic Client Profile that suggests
that Section 2.3 is optional. I also could not find any definition for " non-dynamic OpenID Connect Server".

I dont think there is a need to duplicate portions of the draft specification text in a new document. One solution
that was used in SAML 2.0 was to define a conformance document which described several different
operational modes and explained how only a small set of features needed to be implemented in certain modes.

Given this situation, I do think its a reasonable task for the OAuth community to consider the need for
a minimal extension to OAuth that accommodates authentication. The community should be made aware that
RFC 6749 is being misused for federated authentication, as explained in  -

and that there doesn't appear to be a simple solution that is currently available. It would be great if it turned
out that OpenID Connect offered such a solution but that isn't clear to me.

Thx,
prateek

Inline:

2013/7/31 Prateek Mishra <[email-masked]<mailto:[email-masked]>>
Nat -

your blog posting is helpful to those of us who are looking for a minimal extension of OAuth with
an authenticator.  Many implementors are seeking a modest extension of OAuth, not an entire new protocol
stack.   I believe that is the point of Phil Hunt's proposal to the OAuth committee.

A) Can you direct me to a single OpenID Connect draft specification document where steps 1 and 2 are described?

B) If I implement steps 1 and 2, do I then have a conformant OpenID Connect implementation? Are there no
other MTI protocol exchanges in OpenID Connect?

Nat

Thanks,
prateek

I have written a short blog post titled "Write an OpenID Connect server in three simple steps<http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/>".

e.g.,

Nat

2013/7/31 John Bradley <[email-masked]<mailto:[email-masked]>>
Connect dosen't require a userinfo endpoint.   It is required for interoperability if you are building an open IdP.   For an enterprise type deployment discovery, registration, userifo are all optional.

Justin is correct.

John B.

On 2013-07-30, at 5:30 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Forgot reply all.

Phil

Begin forwarded message:

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: 30 July, 2013 17:25:46 GMT+02:00
To: "Richer, Justin P." <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

Phil

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 31 Jul 2013 22:26:26 -0400

I think the point is that OIDC also includes many other interactions 
that go well beyond an AuthN extension to OAuth.

We are trying to establish whether anyone other than the authors can 
figure out the minimal extension of OAuth that includes AuthN, and 
further, precisely which components are MTI.

To the extent that OIDC is a draft specification vs. "documentation", it 
would be helpful if that was made clearer.  The whole point of a 
*standard* is that these matters should be accessible to a broad 
audience, not just to a small set of expert insiders.

- prateek
> Rather than extending OAuth for something OpenID already does...  why 
> don't we get a simple informational example doc to show how to 
> implement the most basic OpenID service, which is the same 
> functionality on a standard that's already written?
>
> ------------------------------------------------------------------------
> *From:* Prateek Mishra <[email-masked]>
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* "[email-masked] WG" <[email-masked]>
> *Sent:* Wednesday, July 31, 2013 2:38 PM
> *Subject:* [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: 
> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)
>
> Nat -
>
>>>         Connect dosen't require a userinfo endpoint.   It is
>>>         required for interoperability if you are building an open
>>>         IdP. For an enterprise type deployment discovery,
>>>         registration, userifo are all optional.
>>>
>>>>>>         What do you mean? You absolutely can implement a
>>>>>>         compliant OIDC server nearly as simply as this. The
>>>>>>         things that you're missing I think are necessary for
>>>>>>         basic interoperable functionality, and are things that
>>>>>>         other folks using OAuth for authentication have also
>>>>>>         implemented. Namely:
>>>>>>
>>>>>>         Additionally, something that's really important to
>>>>>>         support is the User Info Endpoint, so you can actually
>>>>>>         get user profile information beyond just the simple
>>>>>>         "someone was here" claim -- this was the real value of
>>>>>>         Facebook Connect from an RP's perspective. Some people
>>>>>>         will probably want to use SCIM for this, too, and that's
>>>>>>         fine.
>>>>>>
>>>>>>          -- Justin
>>>>>>
>>>>>>>>         specified as a JWT. You named it "session_token"
>>>>>>>>         instead of "id_token", and you've left off the User
>>>>>>>>         Information Endpoint -- but other than that, this is
>>>>>>>>         exactly the Basic Client for OpenID Connect. In other
>>>>>>>>         words, if you change the names on things you've got
>>>>>>>>         OIDC, but without the capabilities to go beyond a very
>>>>>>>>         basic "hey there's a user here" claim. This is the same
>>>>>>>>         place that OpenID 2.0 started, and it was very, very
>>>>>>>>         quickly extended with SREG, AX, PAPE, and others for it
>>>>>>>>         to be useful in the real world of distributed logins.
>>>>>>>>         You've also left out discovery and registration which
>>>>>>>>         are required for distributed deployments, but I'm
>>>>>>>>         guessing that those would be modular components that
>>>>>>>>         could be added in (like they are in OIDC).
>>>>>>>>
>>>>>>>>         I've heard complaints that OIDC is complicated, but
>>>>>>>>         it's really not. Yes, I agree that the giant stack of
>>>>>>>>         you've got an OAuth2 authorization server that spits
>>>>>>>>         out access tokens and id tokens. The id token is a JWT
>>>>>>>>         with some known claims (iss, sub, etc) and is issued
>>>>>>>>         along side the access token, and its audience is the
>>>>>>>>         *client* and not the *protected resource*. The access
>>>>>>>>         token is a regular old access token and its format is
>>>>>>>>         undefined (so you can use it with an existing OAuth2
>>>>>>>>         server setup, like we have), and it can be used at the
>>>>>>>>         User Info Endpoint to get profile information about the
>>>>>>>>         user who authenticated. It could also be used for other
>>>>>>>>         services if your AS/IdP protects multiple things.
>>>>>>>>
>>>>>>>>         proposition in this spec when we have something that
>>>>>>>>         can do this already? And this doesn't seem to do
>>>>>>>>         anything different (apart from syntax changes)?
>>>>>>>>
>>>>>>>>          -- Justin
>>>>>>>>
>>>>>>>>>         I know several of us have blogged on the issue over
>>>>>>>>>         the past year so I won't re-hash it here.  In short,
>>>>>>>>>         many of us recommended OIDC as the correct methodology.
>>>>>>>>>
>>>>>>>>>         This draft is intended as a minimum authentication
>>>>>>>>>         only specification.  I've tried to make it as
>>>>>>>>>         compatible as possible with OIDC.
>>>>>>>>>
>>>>>>>>>         For now, I've just posted to keep track of the issue
>>>>>>>>>         so we can address at the next re-chartering.
>>>>>>>>>

---

From: William Mills <[email-masked]>
Date: Wed, 31 Jul 2013 19:31:13 -0700 (PDT)

Understood, and this ia precisely what needs to be put into something titled like "OIDC Common Use Cases: A Minimal AuthN Implementation"

Sent from Yahoo! Mail on Android

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 1 Aug 2013 06:27:17 +0200

+1

I am trying to figure out how we can streamline the documentations.
Now that we are done with the implementer's draft vote that diff is not
that important any more as technical content is determined and IPR is
locked in, now is the time to do a major surgery to fix the documentation
clutter that is caused by its history.

There are several proposals on the table right now in the AB/Connect WG at
OIDF.

My proposal at the moment is to reorganize the doc into:

   - OpenID Connect Core
   - OpenID Connect Discovery
   - OpenID Connect Dynamic Registration
   - OpenID Connect Advanced Claims Extension
   - OpenID Connect Advanced Client Authentication Methods Extension
   - OpenID Connect Self-Issued Provider Extension
   - OpenID Connect JSON Based Request Extension

Currently, I am experimenting with whether keeping the different flows in
the Core makes sense or it is better to split them out.

Here is the link to the Core draft I am experimenting with:
http://bit.ly/19yHvJB
XML and HTML versions are in the same repository as well.

Your input will be most welcome.

Nat

2013/8/1 Richer, Justin P. <[email-masked]>

>  +1
>
>  On Jul 31, 2013, at 5:49 PM, Bill Mills <[email-masked]> wrote:
>
> don't we get a simple informational example doc to show how to implement
> the most basic OpenID service, which is the same functionality on a
> standard that's already written?
>
>   ------------------------------
> *Subject:* [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd:
> New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)
>
>  Nat -
>