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 <jric...@mitre.org
<mailto:jric...@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:gffle...@aol.com]
*Sent:* Tuesday, August 13, 2013 7:40 AM
*To:* Anthony Nadalin
*Cc:* m...@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
