For this, I would suggest: Anonymous, user assisted registration - client registers using the client credential flow but may use an administrator (in the case of web app) or end-user (uid/password) . Since resource owner would still require separate credential, then the client flow could be used even though we are passing end-user creds. Client obtains access token limited to registering the new entity.
Anonymous unassisted registration (no user present) - the only solution I can come up with is the client self asserted client_id (e.g. UUID) that the token endpoint chooses to accept if scope equals "registration" (or whatever the scope is to be for registration). IMHO this should be avoided. 3rd Party Assertion - client presents signed assertion in the form of JWT or SAML Bearer assertion and exchanges for an access token. Access is limited to registering a new entity. The value of the access token being short lived or potentially even single-use (or limited use, like 3 tries), would be to prevent abuse of the registration end-point. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-05-30, at 11:59 AM, Justin Richer wrote: > But this still doesn't address clients who don't have a client_secret. Do > they now need one in order to talk to the registration endpoint? What you're > suggesting is that a client use one set of credentials to get access tokens > and another set of credentials to get registrations. This is certainly no > simpler. > > And this exact functionality was tried, implemented, and rejected as too > complicated by the OpenID Connect community. I don't see why it'd be any > different the second time around. > > I really don't see any reason to change it. > > -- Justin > > On 05/30/2013 02:56 PM, Phil Hunt wrote: >> It's hard to say what the best solution here is regarding clarifications >> until we get clarity on the issue of registration access token. >> >> I don't think using a client credential flow to obtain an access token to >> the registration endpoint is complex. It's the normal flow. >> >> I concede that you are looking at it as using Client Credential to get an >> access token to get a new Client Credential. But that's not really what is >> happening in terms of protocol here. >> >> If you take the perspective that the client needs to occasionally update >> registration (e.g. because of a pending credential expiry), then it is still >> simple. You use client credential flow to obtain an access token to update >> registration. Then, from the context of the REST API, the client credential >> is just another piece of JSON data. >> >> IOW from the REST perspective, it is the registration endpoint that is being >> updated, not the client credential. The client credential is just data in >> the perspective of REST. >> >> I think you may be inferring complexity where there really is none. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> On 2013-05-30, at 11:33 AM, Justin Richer wrote: >> >>> Thanks for clearing up where the confusion was taking place. I had tried to >>> make it clear that these were absolutely standard, opaque OAuth2 bearer >>> tokens and absolutely standard OAuth2-protected endpoints, but if that's >>> not clear that needs to be updated. This is what the text says right now: >>> >>> The Client Registration Endpoint MAY accept an Initial Access Token in the >>> form of an OAuth 2.0 [RFC6749] access token to limit registration to only >>> previously authorized parties. The method by which the Initial Access Token >>> is obtained by the registrant is generally out-of-band and is out of scope >>> of this specification. >>> >>> And: >>> >>> The Client Configuration Endpoint is an OAuth 2.0 protected resource that >>> is provisioned by the server for a specific client to be able to view and >>> update its registered information. The location of this endpoint is >>> communicated to the Client through the registration_client_uri member of >>> the Client Information Response [client-info-response]. The Client MUST use >>> its Registration Access Token in all calls to this endpoint as an OAuth 2.0 >>> Bearer Token [RFC6750]. >>> >>> Along with the definitions in the introduction: >>> Registration Access Token >>> OAuth 2.0 Bearer Token issued by the Authorization Server through the >>> Client Registration Endpoint that is used to authenticate the caller when >>> accessing the Client's registration information at the Client Configuration >>> Endpoint. This Access Token is associated with a particular registered >>> Client. >>> Initial Access Token >>> An OAuth 2.0 Access Token optionally issued by an Authorization Server >>> granting access to its Client Registration Endpoint. >>> >>> I'd welcome any proposed changes to the text to make this clearer. >>> >>> As to the other suggestion, what you're saying is to use the client >>> credentials to get an access token to get the client credentials ... ? I >>> can see the argument for using the oauth client credentials flow, but I >>> think that's far more complicated than an endpoint saying "here's a token, >>> go use it", personally. Besides, not all clients have credentials at the >>> token endpoint, so it's a bit of a non-starter for a large class of clients. >>> >>> -- Justin >>> >>> >>> On 05/30/2013 01:55 PM, Phil Hunt wrote: >>>> I see what is happening. >>>> >>>> I think the reason why I find this spec sooo confusing is that the terms >>>> imply new token types when they don't. >>>> >>>> For example when you say "Registration Access Token" and "Initial Access >>>> Token" it implies to me that it is a totally new token type (and in one >>>> case it sorta is). When you read the spec (particularly draft 10) it is >>>> easy to assume something very different is going on. Hence my push back. >>>> >>>> It is now clear to me that what you mean to say is *Access Token used for >>>> initial access* and *Access Token used for registration*. >>>> >>>> Why not write the draft to make clear that the registration end point is >>>> just a NORMAL OAuth2 Enabled REST endpoint? That way you can eliminate >>>> all of the terminology and lifecycle around access tokens except to say >>>> the endpoint is accessed by tokens issued based on the scope >>>> "oauth2:registration". >>>> >>>> That only brings issues with the registration token. The "Access Token >>>> used for registration" seems to have special lifecycle differences. >>>> 1. Issed by reg endpoint as part of successful registration >>>> 2. Has a different lifetime than the client credential (whatever it is). >>>> >>>> Why not again simplify and follow normal OAuth2 pattern and have the >>>> access token issued for registration be *short* lived. Each time the >>>> client wants to either initially register or update its profile it must >>>> request a normal access token with scope "oauth2:registration". >>>> >>>> As for client credential expiry, why not simply require the client to >>>> update its registration before it expires? Why have a long-lived >>>> "registration access token" that has to be managed as well? >>>> >>>> Maybe now I am completely confused? >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote: >>>> >>>>> The issue is that it has different issuing/lifecycle than normal. E.g. >>>>> Why is it issued by the registration endpoint? >>>>> >>>>> Why doesn't the client just request an access token using its client >>>>> credential for the registration endpoint when it wants to update its >>>>> profile? >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote: >>>>> >>>>>> The reg access token is a OAuth bearer token that is issued as part of >>>>>> the registration response and used to access the new client resource for >>>>>> reads and or updates depending on the permissions. >>>>>> >>>>>> They are both oauth access tokens. >>>>>> >>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>>>>> >>>>>>> Seriously. The new dyn reg draft introduces two new tokens. The initial >>>>>>> reg token and the registration access token. >>>>>>> >>>>>>> As for the latter, the reg access token, my understanding is it has >>>>>>> nothing to do with an access token. It is issued *after* registration >>>>>>> to allow reg updates. Right? I know some are confused about this. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On 2013-05-30, at 8:52, Phil Hunt <phil.h...@oracle.com> wrote: >>>>>>> >>>>>>>> No different issue. I was concerned about the initial client assertion >>>>>>>> being passed in as authen cred. It is a signed set of client reg >>>>>>>> metadata. >>>>>>>> >>>>>>>> See we are confused. Hence my worry. :-) >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On 2013-05-30, at 8:48, John Bradley <ve7...@ve7jtb.com> wrote: >>>>>>>> >>>>>>>>> I think Phil also had some processing reason why a Token endpoint or >>>>>>>>> RS wouldn't want to tale the authentication as a header, as the >>>>>>>>> processing was easier with them as parameters as they are potentially >>>>>>>>> available to different parts of the stack. That may have been >>>>>>>>> mostly around RS, but the principal may apply to the token endpoint >>>>>>>>> as well. >>>>>>>>> >>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer <jric...@mitre.org> wrote: >>>>>>>>> >>>>>>>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>>>>>>> BASIC and POST are essentially the same just different ways to >>>>>>>>>>>>> send the client secret. If an authorization server supports both, >>>>>>>>>>>>> both should work for any client. So are both methods treated >>>>>>>>>>>>> differently? >>>>>>>>>>>> I agree, and this was one of my original arguments for making this >>>>>>>>>>>> field plural (or plural-able), but there hasn't been WG support >>>>>>>>>>>> for that so far. >>>>>>>>>>> I'm not arguing to make it plural. I think the authentication >>>>>>>>>>> method is just "client_secret". >>>>>>>>>> That was also an option that was brought up, but in the OIDC WG the >>>>>>>>>> counter-argument was (as I recall) that the two are syntactically >>>>>>>>>> separate and there's a desire to restrict to a single type, such as >>>>>>>>>> disabling client_secret_post. Basically, to make it unambiguous. >>>>>>>>> _______________________________________________ >>>>>>>>> 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
