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

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 <jricher@mitre.org
>> <mailto:jricher@mitre.org>> 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:gffletch@aol.com]
>>>> *Sent:* Tuesday, August 13, 2013 7:40 AM
>>>> *To:* Anthony Nadalin
>>>> *Cc:* mike@gluu.org; Justin Richer; oauth@ietf.org
>>>> *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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>