Subject: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

From: [email-masked]
Date: Thu, 08 Aug 2013 15:22:44 -0500

OAuth WG,

As some of you may know, the OX open source project provides an 
implementation of Enterprise UMA, which enables organizations to control 
which people and clients can access web resources.

I rarely weigh in, because you all are doing such great job. However, I 
was quite distressed to learn about the suggestion to stop work on the 
dynamic client registration spec. This proposed change would have a 
negative impact on OX, and the varied adopters of our software from 
around the world.

No standard for dynamic client registration would make OX less 
"standard" by creating a bigger delta between UMA and other OAuth2 
implementations. As OX also implements the OpenID Connect OP endpoints, 
and dropping this effort would also makes a convergence path for client 
registration less likely.

Please leave dynamic client registration!

Thanks for all your great work!

- Mike Schwartz
Founder / CEO
Gluu
http://gluu.org

PS: Help us crowd fund open source OAuth2 plugins for Apache HTTPD : 
http://www.gluu.co/uma-apache

---

From: Phil Hunt <[email-masked]>
Date: Mon, 12 Aug 2013 16:55:05 -0700

I don't think there is a call to stop work. However there is a lack of consensus on the current draft moving forward. 

I too want a single, simple solution. 

Phil

On 2013-08-08, at 13:22, [email-masked] wrote:

> OAuth WG,
> 
> As some of you may know, the OX open source project provides an implementation of Enterprise UMA, which enables organizations to control which people and clients can access web resources.
> 
> I rarely weigh in, because you all are doing such great job. However, I was quite distressed to learn about the suggestion to stop work on the dynamic client registration spec. This proposed change would have a negative impact on OX, and the varied adopters of our software from around the world.
> 
> No standard for dynamic client registration would make OX less "standard" by creating a bigger delta between UMA and other OAuth2 implementations. As OX also implements the OpenID Connect OP endpoints, and dropping this effort would also makes a convergence path for client registration less likely.
> 
> PS: Help us crowd fund open source OAuth2 plugins for Apache HTTPD : http://www.gluu.co/uma-apache
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Tue, 13 Aug 2013 09:34:02 -0400

I know I wasn't at the IETF meeting but I'm confused regarding all this 
talk of "lack of consensus". It seems to me there is a lot of consensus 
regarding the existing spec (given all the current implementations). 
Couple that with the fact that the current spec doesn't exclude the 
additional use cases that you've raised, I don't see why we don't 
establish the current spec as the core document and then develop 
profiles for the additional use cases. It is unlikely that there is 
going to be a true single solution because to cover all the use cases it 
will have to be so flexible that profiles will arise regardless. In that 
case, let's build off the solid core that we have and add these 
additional profiles providing a win-win for implementers.

My 2 cents:)

Thanks,
George

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Aug 2013 15:55:59 +0200

Hi George, Hi Mike,

as expressed in my mails I am certainly interested to hear what 
implementers currently need and what their timelines are. If you have 
someone I need to talk to please let me know. Maybe you are one of the 
implementers.

I also believe that there isn't a single solution that will fit all 
scenarios. Use cases will help us to find out what the core components 
need to be and what other functionality we can easily "outsource" into 
extensions.

I also wanted to clarify that I am not suggesting to stop the work on 
dynamic client registration; on the contrary I am hoping to expedite the 
work by using the design team.

Various folks have entered their preference into the webpage already 
(see http://moreganize.com/bltr4C3YmGj). Let me know if you have time as 
well.

Ciao
Hannes

On 08/13/2013 03:34 PM, George Fletcher wrote:
>> On 2013-08-08, at 13:22,[email-masked]  wrote:
>>
>>> OAuth WG,
>>>
>>> PS: Help us crowd fund open source OAuth2 plugins for Apache HTTPD :http://www.gluu.co/uma-apache
>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Aug 2013 09:59:09 -0400

+1

On 08/13/2013 09:34 AM, George Fletcher wrote:
> I know I wasn't at the IETF meeting but I'm confused regarding all 
> this talk of "lack of consensus". It seems to me there is a lot of 
> consensus regarding the existing spec (given all the current 
> implementations). Couple that with the fact that the current spec 
> doesn't exclude the additional use cases that you've raised, I don't 
> see why we don't establish the current spec as the core document and 
> then develop profiles for the additional use cases. It is unlikely 
> that there is going to be a true single solution because to cover all 
> the use cases it will have to be so flexible that profiles will arise 
> regardless. In that case, let's build off the solid core that we have 
> and add these additional profiles providing a win-win for implementers.
>
> My 2 cents:)
>
> Thanks,
> George
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Aug 2013 10:16:46 -0400

We have:

https://id.mitre.org/connect/

  -- Justin

On 08/13/2013 10:15 AM, Anthony Nadalin wrote:
>
> Who has implemented draft-ietf-oauth-dyn-reg-14 
> <http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/> and is in 
> production (of some sort) ? We have no plans to implement as it does 
> not meet our requirements/use cases and causes additional management 
> and thus I believe would not serve as a valid core document to expand 
> upon.
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Richer
> *Sent:* Tuesday, August 13, 2013 6:59 AM
> *To:* George Fletcher
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [OAUTH-WG] OX needs Dynamic Registration: please don't 
> remove!
>
> +1
>
>     doesn't exclude the additional use cases that you've raised, I
>     don't see why we don't establish the current spec as the core
>     document and then develop profiles for the additional use cases.
>     It is unlikely that there is going to be a true single solution
>     because to cover all the use cases it will have to be so flexible
>     that profiles will arise regardless. In that case, let's build off
>     the solid core that we have and add these additional profiles
>     providing a win-win for implementers.
>
>     My 2 cents:)
>
>     Thanks,
>     George
>
>         On 2013-08-08, at 13:22,[email-masked]  <mailto:[email-masked]>  wrote:
>
>           
>
>             OAuth WG,
>
>               
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: [email-masked]
Date: Tue, 13 Aug 2013 09:21:54 -0500

Anthony,

As I mentioned, we are using it as part of the OX UMA implementation. 
Can you be more specific?
   1) What parts of it would cause add'l management?
   2) What parts do not meet your requirements that could not be 
satisfied with a
      supplemental profile?

- Mike

On 2013-08-13 09:15, Anthony Nadalin wrote:
> Who has implemented draft-ietf-oauth-dyn-reg-14 [5] and is in
> FROM: [email-masked] [mailto:[email-masked]] ON
> BEHALF OF Justin Richer
>  SENT: Tuesday, August 13, 2013 6:59 AM
>  TO: George Fletcher
>  CC: [email-masked]; [email-masked]
>  SUBJECT: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't 
> remove!
>
> +1
>
>>> I don't think there is a call to stop work. However there is a lack 
>>> of consensus on the current draft moving forward.
>>>
>>>> implementation of Enterprise UMA, which enables organizations to 
>>>> control which people and clients can access web resources.
>>>>
>>>> I rarely weigh in, because you all are doing such great job. 
>>>> However, I was quite distressed to learn about the suggestion to 
>>>> stop work on the dynamic client registration spec. This proposed 
>>>> change would have a negative impact on OX, and the varied adopters 
>>>> of our software from around the world.
>>>>
>>>> implementations. As OX also implements the OpenID Connect OP 
>>>> endpoints, and dropping this effort would also makes a convergence 
>>>> path for client registration less likely.
>>>>
>>>> http://gluu.org [1]
>>>> PS: Help us crowd fund open source OAuth2 plugins for Apache HTTPD 
>>>> : http://www.gluu.co/uma-apache [2]
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth [3]
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth [3]
>>
>> --
>> [4]
>>
>> https://www.ietf.org/mailman/listinfo/oauth [3]
>
>
>
> Links:
> ------
> [1] http://gluu.org
> [2] http://www.gluu.co/uma-apache
> [3] https://www.ietf.org/mailman/listinfo/oauth
> [4] http://connect.me/gffletch
> [5] http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 13 Aug 2013 14:34:19 +0000

So, (1) Management of the secret causes us management issues, yet another endpoint to manage, there may be ways around this issue with assertions. (2) The schema/data model are not useable as defined. Internationalization is an issue. Multi-tenant issues, this also goes back to schema/data model.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 13, 2013 7:22 AM
To: Anthony Nadalin
Cc: Justin Richer; George Fletcher; [email-masked]
Subject: RE: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

Anthony,

As I mentioned, we are using it as part of the OX UMA implementation. 
Can you be more specific?
   1) What parts of it would cause add'l management?
   2) What parts do not meet your requirements that could not be satisfied with a
      supplemental profile?

- Mike

On 2013-08-13 09:15, Anthony Nadalin wrote:
> FROM: [email-masked] [mailto:[email-masked]] ON BEHALF 
> OF Justin Richer

---

From: George Fletcher <[email-masked]>
Date: Tue, 13 Aug 2013 10:40:09 -0400

Hi Tony,

Could you please explain a little more?

For issue 1:
* Which "secret" are you referring to? OAuth2 by default allows for an 
optional client_secret. I'm not sure why this would cause management 
issues? Or are you referring to the "Registration Access Token"?
* Why is a separate endpoint an issue? Any client is going to be talking 
to more than just the /authorize and /token endpoints anyway so I'm 
confused regarding the extra complexity?

For issue 2:
* What specifically do you mean by "multi-tenant"? Is this one server 
acting on behalf of multiple tenants and so appearing as multiple 
Authorization Servers?

Thanks,
George

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 13 Aug 2013 14:15:11 +0000

Who has implemented draft-ietf-oauth-dyn-reg-14<http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/> and is in production (of some sort) ? We have no plans to implement as it does not meet our requirements/use cases and causes additional management and thus I believe would not serve as a valid core document to expand upon.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, August 13, 2013 6:59 AM
To: George Fletcher
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

+1
On 08/13/2013 09:34 AM, George Fletcher wrote:
I know I wasn't at the IETF meeting but I'm confused regarding all this talk of "lack of consensus". It seems to me there is a lot of consensus regarding the existing spec (given all the current implementations). Couple that with the fact that the current spec doesn't exclude the additional use cases that you've raised, I don't see why we don't establish the current spec as the core document and then develop profiles for the additional use cases. It is unlikely that there is going to be a true single solution because to cover all the use cases it will have to be so flexible that profiles will arise regardless. In that case, let's build off the solid core that we have and add these additional profiles providing a win-win for implementers.

My 2 cents:)

Thanks,
George

Phil

On 2013-08-08, at 13:22, [email-masked]<mailto:[email-masked]> wrote:

OAuth WG,

- Mike Schwartz

Founder / CEO

Gluu

http://gluu.org

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--
[George              Fletcher]<http://connect.me/gffletch>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 13 Aug 2013 14:46:26 +0000

#1, its yet another endpoint to have to manage secrets at, yes this is an OAuth item but it’s growing out of control, we are trying to move away from secrets and management of these endpoints as this would be just another one we have to support, monitor and report on
#2 yes, 1 physical endpoint acting as multiple authorization servers

From: George Fletcher [mailto:[email-masked]]
Sent: Tuesday, August 13, 2013 7:40 AM
To: Anthony Nadalin
Cc: [email-masked]; Justin Richer; [email-masked]
Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

Hi Tony,

For issue 1:
* Which "secret" are you referring to? OAuth2 by default allows for an optional client_secret. I'm not sure why this would cause management issues? Or are you referring to the "Registration Access Token"?
* Why is a separate endpoint an issue? Any client is going to be talking to more than just the /authorize and /token endpoints anyway so I'm confused regarding the extra complexity?

For issue 2:
* What specifically do you mean by "multi-tenant"? Is this one server acting on behalf of multiple tenants and so appearing as multiple Authorization Servers?

Thanks,
George

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

To: Anthony Nadalin

Cc: Justin Richer; George Fletcher; [email-masked]<mailto:[email-masked]>

Anthony,

      supplemental profile?

- Mike

upon.

FROM: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] ON BEHALF

OF Justin Richer

 TO: George Fletcher

 CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

remove!

+1

and add these additional profiles providing a win-win for

implementers.

My 2 cents:)

Thanks,

George

Phil

OAuth WG,

- Mike Schwartz

Founder / CEO

Gluu

http://gluu.org [1]

OAuth mailing list

OAuth mailing list

--

[4]

OAuth mailing list

Links:

------

[1] http://gluu.org

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Aug 2013 10:48:12 -0400

The spec doesn't care where you deploy at -- if URL space is at a 
premium for you, then switch based on input parameters and other things. 
And you're still not clear on which "secrets" you're taking issue with.

  -- Justin

On 08/13/2013 10:46 AM, Anthony Nadalin wrote:
>
> #1, its yet another endpoint to have to manage secrets at, yes this is 
> an OAuth item but it’s growing out of control, we are trying to move 
> away from secrets and management of these endpoints as this would be 
> just another one we have to support, monitor and report on
>
> *From:*George Fletcher [mailto:[email-masked]]
> *Sent:* Tuesday, August 13, 2013 7:40 AM
> *To:* Anthony Nadalin
> *Cc:* [email-masked]; Justin Richer; [email-masked]
> * Why is a separate endpoint an issue? Any client is going to be 
> talking to more than just the /authorize and /token endpoints anyway 
> so I'm confused regarding the extra complexity?
>
> For issue 2:
>     From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]]
>
>     Cc: Justin Richer; George Fletcher;[email-masked]  <mailto:[email-masked]>
>
>         FROM:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] ON BEHALF
>
>         OF Justin Richer
>
>           CC:[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>
>                     :http://www.gluu.co/uma-apache  [2]
>
>                       
>
>         [1]http://gluu.org
>         [2]http://www.gluu.co/uma-apache
>
>         [3]https://www.ietf.org/mailman/listinfo/oauth
>
>         [4]http://connect.me/gffletch
>
>         [5]http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/
>
>       
>
> --

---

From: Phil Hunt <[email-masked]>
Date: Tue, 13 Aug 2013 08:00:05 -0700

Dyn reg and the scim reg variant depend too much/biased towards  passwords expressed as client secrets. 

A signed token approach has many advantages for service providers like not having to maintain a secure database of secrets/passwords. 

Finally issuing both a client secret and registration token is costly and confusing to client developers.  I relented somewhat when I realized kerberos does this--but i still feel it is a bad design at cloud scale. 

Phil

On 2013-08-13, at 7:48, Justin Richer <[email-masked]> wrote:

> The spec doesn't care where you deploy at -- if URL space is at a premium for you, then switch based on input parameters and other things. And you're still not clear on which "secrets" you're taking issue with.
> 
>  -- Justin
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 13 Aug 2013 11:01:58 -0400

> just another one we have to support, monitor and report on
So I don't see the "Registration Access Token" as a "secret" but if you 
mean that the client has to keep it protected in some way then I at 
least understand what you are referring to:) However, from what I've 
seen with all these protocols (OAuth2, Dyn Reg, OIDC, ..) the client HAS 
to protect some value anyway. Once the client has determine what that 
mechanism is... it's not hard to store another value so I don't get the 
argument.

If the plan is to leverage on device trusted hardware to sign "data" for 
proof of the client, then that still works with this spec. It's just the 
"Initial Access Token" and potentially the "Registration Access Token" 
can be self-asserted by the "client" rather than storing a value. I 
don't see the complexity.

> #2 yes, 1 physical endpoint acting as multiple authorization servers
This same requirement came up in OIDC and the solution was to use a 
specific path on the host to represent the tenant. That same solution 
will work here with out any changes. Each tenant has it's own 
registration URL.

Am I missing something?

Thanks,
George

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Aug 2013 11:05:22 -0400

You can definitely issue or use other kinds of secrets with both dyn reg 
and the scim variant -- this was the reason we made a registry for the 
token_endpoint_auth_method at your (Phil's) request. Thing is, there 
weren't documents that described the authentication mechanisms that we 
could directly point to. OIDC has a method of using a client's own 
public key (which gets registered with jwks_uri), but that wasn't 
general enough to include here so we left it in the OIDC extension 
document, where it belongs. In that case, the client wouldn't get a 
client_secret. The same is true if you issue a client_assertion as part 
of the registration process.

It would get a registration_access_token, though, so that it can manage 
its own registration if needed. But that's just a very basic OAuth2 
Bearer token, and if your OAuth server can't handle issuing and 
validating OAuth tokens, you probably shouldn't be letting clients 
register themselves anyway. ;)

  -- Justin

On 08/13/2013 11:00 AM, Phil Hunt wrote:
> A signed token approach has many advantages for service providers like 
> not having to maintain a secure database of secrets/passwords.
>
> Finally issuing both a client secret and registration token is costly 
> and confusing to client developers.  I relented somewhat when I 
> realized kerberos does this--but i still feel it is a bad design at 
> cloud scale.
>
> Phil
>
> On 2013-08-13, at 7:48, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> premium for you, then switch based on input parameters and other 
>> things. And you're still not clear on which "secrets" you're taking 
>> issue with.
>>
>>  -- Justin
>>
>>> #1, its yet another endpoint to have to manage secrets at, yes this 
>>> is an OAuth item but it’s growing out of control, we are trying to 
>>> move away from secrets and management of these endpoints as this 
>>> would be just another one we have to support, monitor and report on
>>>
>>> *Subject:* Re: [OAUTH-WG] OX needs Dynamic Registration: please 
>>> don't remove!
>>>
>>> Hi Tony,
>>>
>>> * Which "secret" are you referring to? OAuth2 by default allows for 
>>> an optional client_secret. I'm not sure why this would cause 
>>> management issues? Or are you referring to the "Registration Access 
>>> Token"?
>>> * What specifically do you mean by "multi-tenant"? Is this one 
>>> server acting on behalf of multiple tenants and so appearing as 
>>> multiple Authorization Servers?
>>>
>>> Thanks,
>>> George
>>>
>>>  <http://connect.me/gffletch>
>>>
>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 13 Aug 2013 08:16:22 -0700

You missed both my points entirely. 

Phil

On 2013-08-13, at 8:05, Justin Richer <[email-masked]> wrote:

> You can definitely issue or use other kinds of secrets with both dyn reg and the scim variant -- this was the reason we made a registry for the token_endpoint_auth_method at your (Phil's) request. Thing is, there weren't documents that described the authentication mechanisms that we could directly point to. OIDC has a method of using a client's own public key (which gets registered with jwks_uri), but that wasn't general enough to include here so we left it in the OIDC extension document, where it belongs. In that case, the client wouldn't get a client_secret. The same is true if you issue a client_assertion as part of the registration process. 
> 
> It would get a registration_access_token, though, so that it can manage its own registration if needed. But that's just a very basic OAuth2 Bearer token, and if your OAuth server can't handle issuing and validating OAuth tokens, you probably shouldn't be letting clients register themselves anyway. ;)
> 
>  -- Justin
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Aug 2013 17:29:44 +0200

The "Registration Access Token" is, of course, a secret.

If you look at Figure 1 of 
http://tools.ietf.org/id/draft-ietf-oauth-dyn-reg-14.txt you will see 
that the client obtains this secret during step C of the exchange and 
presents it to the Client Registration Endpoint in step D.

Of course, one could argue that the client could as well be given a 
client secret (instead of the Registration Access Token) and that would 
work equally fine.

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Aug 2013 11:32:38 -0400

Except that not all clients get client secrets (clients using the 
implicit flow, clients using assertions). OpenID Connect tried to use 
client_secret for everything, but it turned out to be one of those 
things that seems simple but was really a mess to implement. That's when 
we struck on using an OAuth bearer token and treating the configuration 
endpoint as an OAuth protected resource. It simplifies things 
tremendously, and it lets the client_secret remain for what it's 
intended for, and lets us use OAuth tokens for what they're good at -- 
protecting API resources.

This is all discussed in section 1.4, though I'd be glad to know how we 
could make this more clear.

  -- Justin

On 08/13/2013 11:29 AM, Hannes Tschofenig wrote:
> client secret (instead of the Registration Access Token) and that 
> would work equally fine.
>
>>>     So, (1) Management of the secret causes us management issues, 
>>> yet another endpoint to manage, there may be ways around this issue 
>>> with assertions. (2) The schema/data model are not useable as 
>>> defined. Internationalization is an issue. Multi-tenant issues, this 
>>> also goes back to schema/data model.
>>>
>>>
>>>
>>>
>>>
>>>         FROM:[email-masked] <mailto:[email-masked]> 
>>> [mailto:[email-masked]] ON BEHALF
>>>
>>>         OF Justin Richer
>>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 13 Aug 2013 13:21:17 -0400

Hi Phil,

I'm sorry for not following completely. Some questions inline...

>  passwords expressed as client secrets.
I'm not sure what you mean in regards to "client secrets". There are 
OAuth2 bearer tokens that need to be protected because they are bearer 
tokens. That said, there is nothing in the spec that requires these to 
be opaque blobs vs signed tokens. So both the "Initial Access Token" and 
the "Registration Access Token" can be signed tokens. However, the 
client still has to protect them as if they were a "secret" because they 
are a bearer token and can be replayed. So it's the same amount of work 
on the client either way.

> not having to maintain a secure database of secrets/passwords.
If the concern here is the amount of data the Authorization Server has 
to store to manage these clients, then the current spec doesn't preclude 
using a "signed token". Both OAuth2 bearer tokens identified in the 
current spec can be signed tokens.
> realized kerberos does this--but i still feel it is a bad design at 
Given that client_secrets are OPTIONAL in OAuth2 for some use cases, I'm 
not sure how you abstract the client developer from having to deal with 
them. The client developer is going to be dealing with multiple OAuth2 
tokens to multiple endpoints regardless so I don't see another token as 
costly or complex. At a minimum there is the refresh_token and 
access_token. Where is the added client developer complexity?

Thanks,
George

>>> [snip...]

--

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Aug 2013 08:32:18 +0200

George is correct with his statements. There is, however, a difference 
between a shared secret and an assertion as Phil pointed out. For the 
assertion the server does not need to maintain state on a per-client 
basis. On the other hand since the client secret isn't really used in 
the classical sense of a password either but rather as a "cookie" (if 
used in the style of Section 2.3.1 of RFC6749) one could easy apply the 
concept of stateless tokens to them:
http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Aug 2013 02:29:01 -0700

+1 to Hannes comments. I was referring to the server issues. 

George, I believe only in the openid case and a few others would a client hold tokens to multiple endpoints of the same api. 

For the vast majority of apps, clients would be permanently associated to a single endpoint for the resource endpoint. 

That said, having multiple tokens for multiple endpoints isn't that confusing. But, having multiple tokens for EACH of multiple endpoints is confusing. 

Compound that with the fact that each api endpoint and each reg endpoint may use different types of credentials (passwords, tokens, hoks) and the client has to he pretty darn smart dealing with all the options and permutations. 

1. We need to eliminate reg access tokens as long term retained tokens. If we must have crud than use normal access tokens issued in the normal way. 

2. We need to look to change the design to reduce options at the registration endpoint The assertion swap method is one possibility. 

3. We should also consider amending 6749. For example make client id optional for implicit flow or javascript based on service provider choice. Or depend on a developer issued client id, etc. Dyn reg isn't actually improving security in these cases anyway. Why go through this much work for an identifier if it doesn't help client or server other than the ability to make a conforming call?

Phil

On 2013-08-13, at 23:32, Hannes Tschofenig <[email-masked]> wrote:

> George is correct with his statements. There is, however, a difference between a shared secret and an assertion as Phil pointed out. For the assertion the server does not need to maintain state on a per-client basis. On the other hand since the client secret isn't really used in the classical sense of a password either but rather as a "cookie" (if used in the style of Section 2.3.1 of RFC6749) one could easy apply the concept of stateless tokens to them:

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Aug 2013 11:08:13 -0700

I'm just thinking off the top of my head trying to break through on some simplification possibilities.  The spec so far is driven by OIDC, but the more I think about it, it is a special case of a clients that want to be able to connect to many different OIDC service providers based on an event trigger of some kind (truly dynamic).

When I hear Justin and others describe the drive behind dyn reg, the primary reason stated is because 6749 requires that clients have a client_id. The requirement for client_id to be issued by the AS protecting the endpoint seems to arise from the assumption that client_id must be an identifier the AS accepts.

Yet, 6749 does not make this restriction.

An assertion (e.g. software statement) could serve the same purpose as long as the AS trusts the signer.  So for example, javascript clients could pass a software assertion and avoid the need to register.

Per my previous comment, I am of course assuming that there is little or no value in being able to track execution instances of javascript.

If I were to separate the Software Statement into a separate spec, it could define multiple uses:

1.  [No Reg] As a client_id for javascript / implicit clients

2. [Static Reg] For native clients (ones that use a fixed redirect), a certificate swap per the JWT Bearer spec to exchange for a client assertion.  (would client_id be assigned or would software statement be used?).  These clients are "fixed" and more often than not, tend to associate with one service provider at a time.

3.  [Offline Reg] For web clients -- is registration needed? Why not use an OOB administrative process.  These are large apps with significant trust and network issues that would preclude automatic registration. They tend to connect to one endpoint at a time.

5. [Dyn Reg] Dynamic association clients - There a category of clients that would need full CRUD because of registration time changes in values like redirect_url? Further, the clients may connect randomly to different service providers of the same API. OpenID Connect seems to be one of them. Do these clients need permanent registration?  

Does categorization of clients give a proper justification for having a dyn reg draft plus some other methods for registration?  Or is OIDC so specialized the draft should remain an OIDF draft?  If so, how can we best align?

The one observation I have here about registration and the dynamic registration case is that a hacker could simply keep re-registering and endpoint to change the redirect_url at will. It seems like this is a bad thing.So is the idea to ensure that every time a client returns to an endpoint it somehow MUST use the same registration as before? Honest players might do that (especially incentivized by saving the registration step).  But Dyn Reg would seem not to do this, but rather make it easier to keep registering and thereby dynamically change the redirect_url every time.

Of course a *big* negative about this thinking is that different clients are treated very differently.  I don't like this. Yet, for each treatment, the options are more restrictive and simplified.  I'm not sure this is progress, but thought I would throw the idea out there for discussion.  Maybe someone can take this to another step?

Phil

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

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 15 Aug 2013 11:42:43 +0900

Right. A Bearer Token does not have to be a shared secret. It may have some structure that allows the server to validate it statelessly, e.g. JWS-JWT. 

=nat via iPhone

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Aug 2013 20:47:16 -0700

I am saying a bearer token is better than a password for the service provider as Hannes explains. 

Phil

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Aug 2013 15:59:28 -0400

Yes a bearer token that is signed and or encrypted by the AS reduces the amount of state required for the AS to maintain. 

In RFC 6749 there is information about the client that is tied to the client_id, and is required at the authorization endpoint. (eg redirect_uri)

I understand the goal of reducing state in the IdP.   Some of us have looked at storing information in a signed client_id that would work in the existing RFC 6749 flows.

It seems that some people are dissatisfied with RFC 6749 and would like to see changes like removing implicit flows.

The current Dynamic registration spec deals with the current state of OAuth.   If the WG decides to do a OAuth 3 that fully supports assertions and ditches secrets I would be OK with that. 
However lets not cripple what we have as a standard now by crating dynamic registration that can only be fully implemented  in a future version of OAuth.

Some people want/need a client registration API now.  It is clearly a missing part of an entire OAuth system.   
Supporting existing OAuth while minimizing state at the AS is something I support, waiting for a OAuth redesign is not in my opinion a reasonable medium term goal.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 Aug 2013 13:23:56 -0700

John,

I agree a big part of the problem with Dyn Reg is it has to reflect the current state of 6749 (specifically that clients must have a client_id even though 6749 says nothing about its format or how to obtain one).

Regarding timing (the need to approve dyn reg now): a draft doesn't have to be final for people to implement it into operational production.  In fact, putting into production is a far better validation than mere implementation. The fact that 6749 changed substantially in draft stage did not prevent many from putting it into production.  Why is approval a barrier in this case?  My understanding is the IESG has the option force the draft to wait for operational use before it mores forward (see below).

I'm not sure an OAuth 3 is required here since 6749 is not yet final, rather it is "PROPOSED STANDARD".  In particular, section 4.1.1 of RFC2026 states:

>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.

>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.

> 
>    The IESG may require implementation and/or operational experience
>    prior to granting Proposed Standard status to a specification that
>    materially affects the core Internet protocols or that specifies
>    behavior that may have significant operational impact on the
>    Internet.

This would suggest to me, that some of OAuth issues that drove the design of Dyn-Reg can be more cleanly resolved by amending 6749. Such a change would be permissive, backward compatible, and greatly simplify registration if not eliminate it in many cases.

The subject of improper use of OAuth as an authenticator is also an issue that should be discussed when it comes to moving the proposed standard (OAuth 2) forward.

Phil

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

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Aug 2013 16:35:30 -0400

I believe it is rare for RFC to move beyond the stage RFC 6749 is currently at so It is to most peoples minds finished.

I am not against doing future things to improve the spec.  I just suspect that opening that can of worms again will take time.

John B.

---

From: Eve Maler <[email-masked]>
Date: Thu, 15 Aug 2013 15:17:31 -0700

Agree with John that RFC 6749 is to all intents and purposes final. Also, when we have a dyn reg spec whose earliest drafts are several years old, whose current draft is implemented by a variety of OAuth, OpenID Connect, and UMA developers, whose current design reflects a good deal of healthy consolidation of disparate starting points, and for which there's been concrete demand expressed on this list, I'm a little surprised that there's this much contention about it at this juncture.

	Eve

>>>>>>>>>> multiple Authorization Servers?

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 15 Aug 2013 22:26:56 +0000

This is not new contention, look back in the mailing list, been going on for quite a while. So far I have only seen 2 replies for implementations. The idea is to get things right.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eve Maler
Sent: Thursday, August 15, 2013 3:18 PM
To: John Bradley
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

	Eve

On 15 Aug 2013, at 1:35 PM, John Bradley <[email-masked]> wrote:

>>> known design choices, is believed to be well-understood, has 
>>> received  significant community review, and appears to enjoy enough 
>>> community  interest to be considered valuable.  However, further 
>>> experience  might result in a change or even retraction of the 
>>> specification  before it advances.
>> 
>>> In RFC 6749 there is information about the client that is tied to 
>>> the client_id, and is required at the authorization endpoint. (eg 
>>> redirect_uri)
>>> 
>>>>>>> OAuth2 bearer tokens that need to be protected because they are 
>>>>>>> bearer tokens. That said, there is nothing in the spec that 
>>>>>>> requires these to be opaque blobs vs signed tokens. So both the 
>>>>>>> "Initial Access Token" and the "Registration Access Token" can 
>>>>>>> be signed tokens. However, the client still has to protect them 
>>>>>>> as if they were a "secret" because they are a bearer token and 
>>>>>>> can be replayed. So it's the same amount of work on the client either way.
>>>>>>> 
>>>>>>>> 
>>>>>>>> A signed token approach has many advantages for service 
>>>>>>>> providers like not having to maintain a secure database of secrets/passwords.
>>>>>>> If the concern here is the amount of data the Authorization 
>>>>>>> Server has to store to manage these clients, then the current 
>>>>>>> spec doesn't preclude using a "signed token". Both OAuth2 bearer 
>>>>>>> tokens identified in the current spec can be signed tokens.
>>>>>>>> 
>>>>>>>> Finally issuing both a client secret and registration token is 
>>>>>>>> costly and confusing to client developers.  I relented somewhat 
>>>>>>>> when I realized kerberos does this--but i still feel it is a 
>>>>>>>> bad design at cloud scale.
>>>>>>> Given that client_secrets are OPTIONAL in OAuth2 for some use 
>>>>>>> cases, I'm not sure how you abstract the client developer from 
>>>>>>> having to deal with them. The client developer is going to be 
>>>>>>> dealing with multiple OAuth2 tokens to multiple endpoints 
>>>>>>> regardless so I don't see another token as costly or complex. At 
>>>>>>> a minimum there is the refresh_token and access_token. Where is the added client developer complexity?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> George
>>>>>>> 
>>>>>>>> 
>>>>>>>> Phil
>>>>>>>> 
>>>>>>>>> The spec doesn't care where you deploy at -- if URL space is 
>>>>>>>>> at a premium for you, then switch based on input parameters 
>>>>>>>>> and other things. And you're still not clear on which 
>>>>>>>>> "secrets" you're taking issue with.
>>>>>>>>> 
>>>>>>>>> -- Justin
>>>>>>>>> 
>>>>>>>>>> #1, its yet another endpoint to have to manage secrets at, 
>>>>>>>>>> yes this is an OAuth item but it’s growing out of control, we 
>>>>>>>>>> are trying to move away from secrets and management of these 
>>>>>>>>>> endpoints as this would be just another one we have to 
>>>>>>>>>> support, monitor and report on
>>>>>>>>>> 
>>>>>>>>>> *Subject:* Re: [OAUTH-WG] OX needs Dynamic Registration: 
>>>>>>>>>> please don't remove!
>>>>>>>>>> 
>>>>>>>>>> Hi Tony,
>>>>>>>>>> 
>>>>>>>>>> * Which "secret" are you referring to? OAuth2 by default 
>>>>>>>>>> allows for an optional client_secret. I'm not sure why this 
>>>>>>>>>> would cause management issues? Or are you referring to the 
>>>>>>>>>> "Registration Access Token"?
>>>>>>>>>> * Why is a separate endpoint an issue? Any client is going to 
>>>>>>>>>> be talking to more than just the /authorize and /token 
>>>>>>>>>> endpoints anyway so I'm confused regarding the extra complexity?
>>>>>>>>>> 
>>>>>>>>>> For issue 2:
>>>>>>>>>> * What specifically do you mean by "multi-tenant"? Is this 
>>>>>>>>>> one server acting on behalf of multiple tenants and so 
>>>>>>>>>> appearing as multiple Authorization Servers?
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> George
>>>>>>>>>> 
>>>>>>>>>> [snip...]
>>>>>>>> 
>>>>>>>>

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 15 Aug 2013 18:40:39 -0400

Phil -

i like the taxonomy of clients you described here, my view is that this 
isn't a negative at all, its actually necessary to make progress and 
give good guidance in this area.

OAuth provides a flexible definition of "client" - so naturally, there 
are going to be all kinds of variations and use-cases for client 
registration and self-assertion.

Pretending that there is one flavor of client is actually quite 
confusing to the community (or at least  to me).

- prateek

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 16 Aug 2013 07:32:05 +0200

+1 

Dyn reg should fit into the OAuth system as it is now, which uses client ids and secrets. A (probably) improved OAuth is a completely different topic. Let's handle it separately. 

John Bradley <[email-masked]> schrieb:
>Yes a bearer token that is signed and or encrypted by the AS reduces
>the amount of state required for the AS to maintain. 
>
>In RFC 6749 there is information about the client that is tied to the
>client_id, and is required at the authorization endpoint. (eg
>redirect_uri)
>
>I understand the goal of reducing state in the IdP.   Some of us have
>looked at storing information in a signed client_id that would work in
>the existing RFC 6749 flows.
>
>It seems that some people are dissatisfied with RFC 6749 and would like
>to see changes like removing implicit flows.
>
>The current Dynamic registration spec deals with the current state of
>OAuth.   If the WG decides to do a OAuth 3 that fully supports
>assertions and ditches secrets I would be OK with that. 
>However lets not cripple what we have as a standard now by crating
>dynamic registration that can only be fully implemented  in a future
>version of OAuth.
>
>Supporting existing OAuth while minimizing state at the AS is something
>I support, waiting for a OAuth redesign is not in my opinion a
>reasonable medium term goal.
>
>John B.
>
>
>>> Right. A Bearer Token does not have to be a shared secret. It may
>have some structure that allows the server to validate it statelessly,
>e.g. JWS-JWT. 
>>> 
>>> =nat via iPhone
>>> 
>>>> George is correct with his statements. There is, however, a
>difference between a shared secret and an assertion as Phil pointed
>out. For the assertion the server does not need to maintain state on a
>per-client basis. On the other hand since the client secret isn't
>really used in the classical sense of a password either but rather as a
>"cookie" (if used in the style of Section 2.3.1 of RFC6749) one could
>easy apply the concept of stateless tokens to them:
>bearer
>costly
>cases, I'm
>be
>------------------------------------------------------------------------
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 16 Aug 2013 10:06:36 -0400

+1

Let's not shave a yak quite yet.

On 08/16/2013 01:32 AM, Torsten Lodderstedt wrote:
> +1
>
> Dyn reg should fit into the OAuth system as it is now, which uses 
> client ids and secrets. A (probably) improved OAuth is a completely 
> different topic. Let's handle it separately.
>
>
>
>     Some peopl
>       e
>     want/need a client registration API now.  It is clearly a missing part of an entire OAuth system.
>         I am saying a bearer token is better than a password for the
>         service provider as Hannes explains. Phil On 2013-08-14, at
>         19:42, Nat Sakimura <[email-masked]> wrote:
>
>             Right. A Bearer Token does not have to be a shared secret.
>             It may have some structure that allows the server to
>             validate it statelessly, e.g. JWS-JWT. =nat via iPhone Aug
>             14, 2013 15:32?Hannes Tschofenig
>             <[email-masked]> ??????:
>
>                 George is correct with his statements. There is,
>                 however, a difference between a shared secret and an
>                 assertion as Phil pointed out. For the assertion the
>                 server does not need to maintain state on a per-client
>                 basis. On the other hand since the client secret isn't
>                 really used in the classical sense of a password
>                 either but rather as a "cookie" (if used in the style
>                 of Section 2.3.1 of RFC6749) one could easy apply the
>                     Hi Phil, I'm sorry for not following completely.
>                     Some questions inline... On 8/13/13 11:00 AM, Phil
>                     Hunt wrote:
>
>                         Dyn reg and the scim reg variant depend too
>                         much/biased towards passwords expressed as
>                         client secrets. 
>
>                     I'm not sure what you mean in regards to "client
>                     secrets". There are OAuth2 bearer tokens that need
>                     to be protected because they are bearer tokens.
>                     That said, there is nothing in the spec that
>                     requires these to be opaque blobs vs signed
>                     tokens. So both the "Initial Access Token" and the
>                     "Registration Access Token" can be signed tokens.
>                     However, the client still has to protect them as
>                     if they were a "secret" because they are a bearer
>                     token and can be replayed. So it's the same amount
>                     of work on the client either way .
>
>                         A signed token approach has many advantages
>                         for service providers like not having to
>                         maintain a secure database of secrets/passwords. 
>
>                     If the concern here is the amount of data the
>                     Authorization Server has to store to manage these
>                     clients, then the current spec doesn't preclude
>                     using a "signed token". Both OAuth2 bearer tokens
>                     identified in the current spec can be signed tokens.
>
>                         Finally issuing both a client secret and
>                         registration token is costly and confusing to
>                         client developers. I relented somewhat when I
>                         realized kerberos does this--but i still feel
>                         it is a bad design at cloud scale. 
>
>                     Given that client_secrets are OPTIONAL in OAuth2
>                     for some use cases, I'm not sure how you abstract
>                     the client developer from having to deal with
>                     them. The client developer is going to be dealing
>                     with multiple OAuth2 tokens to multiple endpoints
>                     regardless so I don't see another token as costly
>                     or complex. At a minimum there is the
>                     refresh_token and access_token. Where is the added
>                     client developer complexity? Thanks, George
>
>                         Phil On 2013-08-13, at 7:48, Justin Richer
>                         <[email-masked] <mailto:[email-masked]>>
>                         wrote:
>
>                             The spec doesn't care where you deploy at
>                             -- if URL space is at a premium for you,
>                             then switch based on input parameters and
>                             other things. And you're still not clear
>                             on which "secrets" you're ta king issue
>                             with. -- Justin On 08/13/2013 10:46 AM,
>                             Anthony Nadalin wrote:
>
>                                 #1, its yet another endpoint to have
>                                 to manage secrets at, yes this is an
>                                 OAuth item but it's growing out of
>                                 control, we are trying to move away
>                                 from secrets and management of these
>                                 endpoints as this would be just
>                                 another one we have to support,
>                                 monitor and report on #2 yes, 1
>                                 physical endpoint acting as multiple
>                                 authorization servers *From:*George
>                                 Fletcher [mailto:[email-masked]]
>                                 *Sent:* Tuesday, August 13, 2013 7:40
>                                 AM *To:* Anthony Nadalin *Cc:*
>                                 [email-masked]; Justin Richer;
>                                 [email-masked] *Subject:* Re:
>                                 [OAUTH-WG] OX needs Dynamic
>                                 Registration: please don't remove! Hi
>                                 Tony, Could you please explain a
>                                 little more? For issue 1: * Which
>                                 "secret" are you refe rring to? OAuth2
>                                 by default allows for an optional
>                                 client_secret. I'm not sure why this
>                                 would cause management issues? Or are
>                                 you referring to the "Registration
>                                 Access Token"? * Why is a separate
>                                 endpoint an issue? Any client is going
>                                 to be talking to more than just the
>                                 /authorize and /token endpoints anyway
>                                 so I'm confused regarding the extra
>                                 complexity? For issue 2: * What
>                                 specifically do you mean by
>                                 "multi-tenant"? Is this one server
>                                 Authorization Servers? Thanks, George
>                                 [snip...]
>
>                         OAuth mailing list [email-masked]
>                     OAuth mailing list [email-masked]
>                 OAuth mailing list [email-masked]
>             OAuth mailing list [email-masked]
>         OAuth mailing list [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 16 Aug 2013 07:08:05 -0700

Before everyone gets excited, all John and was referring to was providing further definition on client_id that allows scenarios where the id isn't issued by the AS but rather a federated entity. 

This in no way changes how 6749 works. 

In particular for javascript clients it would avoid the incredible cost of registration for EVERY execution of a script. 

Dyn Reg currently has to assume a client_id must be issued by the as the controls access to the resource endpoint. 

The change here is on the level of errata. Never-the-less we are permitted to change as the standard is technically not final. (Yet as pointed out in practice it is)

Phil

On 2013-08-15, at 22:32, Torsten Lodderstedt <[email-masked]> wrote:

>> Some peop!
>>  le
>>>>>> on the client either wa!
>>>>>>  y.
>>>>>> Given that client_secrets are OPTIONAL in OAuth2 for some use!
>>>>>>   cases,
>>>>>> I'm
>>>>>>>> things. And you're still not clear on which "secrets" you're t!
>>>>>>>>  aking
>>>>>>>> issue with.
>>>>>>>> 
>>>>>>>> -- Justin
>>>>>>>> 
>>>>>>>>> * Which "secret" are you ref!
>>>>>>>>>  erring
>>>>>>>>> to? OAuth2 by default allows for

---

From: Phil Hunt <[email-masked]>
Date: Fri, 16 Aug 2013 07:13:46 -0700

-1

I would say the analogy is this:

Clarify client_id = shave the yak to get the fur
Dyn reg = skin the yak to make access to the fur easier. 

The yak in this case is the SP. 

Dyn reg works but the sp dies under the load in the process. 

Phil

On 2013-08-16, at 7:06, Justin Richer <[email-masked]> wrote:

>>>>>>>>>> * Which "secret" are you refe
>>>>>>>>>>  rring

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 16 Aug 2013 14:26:00 +0000

The yak needs to be sheered to make way for better hair.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Friday, August 16, 2013 7:07 AM
To: Torsten Lodderstedt
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

+1

John Bradley <[email-masked]><mailto:[email-masked]> schrieb:

Some peopl

 e

John B.

On 2013-08-14, at 11:47 PM, Phil Hunt <[email-masked]><mailto:[email-masked]> wrote:

Phil

On 2013-08-14, at 19:42, Nat Sakimura <[email-masked]><mailto:[email-masked]> wrote:

=nat via iPhone

Aug 14, 2013 15:32、Hannes Tschofenig <[email-masked]><mailto:[email-masked]> のメッセージ:

Hi Phil,

Dyn reg and the scim reg variant depend too much/biased towards

passwords expressed as client secrets.

on the client either way

 .

cloud scale.

 cases,

I'm

Thanks,

George

Phil

On 2013-08-13, at 7:48, Justin Richer <[email-masked]<mailto:[email-masked]>

<mailto:[email-masked]><mailto:[email-masked]>> wrote:

things. And you're still not clear on which "secrets" you're ta

 king

issue with.

-- Justin

*To:* Anthony Nadalin

*Cc:* [email-masked]<mailto:[email-masked]>; Justin Richer; [email-masked]<mailto:[email-masked]>

don't remove!

Hi Tony,

For issue 1:

 rring

Token"?

For issue 2:

Thanks,

George

[snip...]

________________________________

OAuth mailing list

--

________________________________

OAuth mailing list

________________________________

OAuth mailing list

________________________________

OAuth mailing list

________________________________

OAuth mailing list

________________________________

OAuth mailing list

OAuth mailing list

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 16 Aug 2013 14:22:43 +0000

-1

Let’s not continue propagating these issues

From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Thursday, August 15, 2013 10:32 PM
To: John Bradley; Phil Hunt
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

+1

John Bradley <[email-masked]<mailto:[email-masked]>> schrieb:

Some peopl

 e

John B.

On 2013-08-14, at 11:47 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On 2013-08-14, at 19:42, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

=nat via iPhone

Aug 14, 2013 15:32、Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> のメッセージ:

Hi Phil,

 .

 cases,

I'm

Thanks,
George

Phil

On 2013-08-13, at 7:48, Justin Richer <[email-masked]
<mailto:[email-masked]<mailto:[email-masked]%0b%3cmailto:[email-masked]>>> wrote:

 king
issue with.

-- Justin

Hi Tony,

For issue 1:

 rring

For issue 2:

Thanks,
George

[snip...]

OAuth mailing list

--

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 16 Aug 2013 22:12:49 +0300

> The current Dynamic registration spec deals with the current state of OAuth.   If the WG decides to do a OAuth 3 that fully supports assertions and ditches secrets I would be OK with that.

Except that developers looking for a simplicity will run away from it. 
Let assertions be supported and such, but please also protect the 
interests of developers who would like to do OAuth2 without IDP + CLoud 
+ encrypted JWT

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 16 Aug 2013 22:17:31 +0300

On 16/08/13 08:32, Torsten Lodderstedt wrote:
> +1
>
> Dyn reg should fit into the OAuth system as it is now, which uses client
> ids and secrets. A (probably) improved OAuth is a completely different
> topic. Let's handle it separately.
+1

Cheers, Sergey
>         service provider as Hannes explains.
>
>         Phil
>
>             validate it statelessly, e.g. JWS-JWT.
>
>             =nat via iPhone
>
>                 really used in the classical sense of a password either
>                 but rather as a "cookie" (if used in the style of
>                 Section 2.3.1 of RFC6749) one could easy apply the
>                         much/biased towards
>                     secrets". There are
>                     on the client either way .
>
>
>                     Authorization Server has
>                         registration token is costly
>                     with multiple OAuth2
>                             things. And you're still not clear on which
>                             "secrets" you're ta king
>                             issue with.
>
>                             -- Justin
>
>                                 * Which "secret" are you refe rring to?
>                                 OAuth2 by default allows for
>                                 complexity?