+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.
John Bradley <ve7...@ve7jtb.com> 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.
Some peopl
e
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.
On 2013-08-14, at 11:47 PM, Phil Hunt <phil.h...@oracle.com> wrote:
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 <sakim...@gmail.com> 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
<hannes.tschofe...@gmx.net> ??????:
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
<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 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: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 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
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
------------------------------------------------------------------------
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
------------------------------------------------------------------------
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
_______________________________________________
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
