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. 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 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 >>> >>> _______________________________________________ >>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
