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

[Phil Hunt <[e-mail]>]

+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 <[e-mail]> 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:
> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01
> 
> 
> On 08/13/2013 07:21 PM, George Fletcher wrote:
>> 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 <[e-mail]
>>> <mailto:[e-mail]>> 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
>>>> 
>>>> 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:[e-mail]]
>>>>> *Sent:* Tuesday, August 13, 2013 7:40 AM
>>>>> *To:* Anthony Nadalin
>>>>> *Cc:* [e-mail]; Justin Richer; [e-mail]
>>>>> *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 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...]
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> --
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>