Authz server and resource server need to agree on a token format. The client never needs to interpret the token content. Since we are talking about clients, where is the connection?
regards, Torsten. Phil Hunt <phil.h...@oracle.com> schrieb: >I think many of the parameters in dyn reg need to be specified in the >statement -- the main change is we're moving dyn reg parameters into >the statement and locking them down between instances. It keeps >hackers from changing individual instances and it minimizes state in >per instance registration. > >The reason OAuth doesn't have to define token formats is they are >largely "local". Federated token scenarios (like UMA) obviously have >to have some OOB agreement on format. Given that registration in most >of these cases is federated, it seems appropriate to define these >assertions. (In the non-federated cases (e.g. like Google), they can do >registration using workflows with the developer directly.) > >Phil > >@independentid >www.independentid.com >phil.h...@oracle.com > > > > > > > >On 2013-08-28, at 9:55 AM, George Fletcher <gffle...@aol.com> wrote: > >> OAuth has never specified anything regarding the format the "tokens" >that the AS has to accept and that's one of it's virtues. It allows for >many implementations from local only to federated. >> >> I fully believe there is value in defining profiles of OAuth for >particular problem domains that put restrictions on client_id format, >access_token format etc (e.g. the assertion set of specs). However, >those should be layered on top of OAuth as a profile and not be forced >into the core. Otherwise, we are forcing all implementations down a >much narrower path than is supported today. I definitely don't want to >see that happen. >> >> Thanks, >> George >> >> On 8/28/13 12:48 PM, Phil Hunt wrote: >>> You can pass anything as a client_id. It just has to be accepted. >That's the point of us writing a draft here isn't it? >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> On 2013-08-28, at 9:45 AM, John Bradley <ve7...@ve7jtb.com> wrote: >>> >>>> That is my concern as well, sending an assertion to the >authorization endpoint requires a extension of OAuth to add another >parameter or placing it in the client_id which you can do now with the >dynamic reg spec if the AS wants to. >>>> >>>> Holding up client registration for something that will require an >extension to OAuth is overdoing it. We need something for the OAuth >spec we have now without requiring clients implement the assertion flow >and other extensions. >>>> >>>> John B. >>>> >>>> On 2013-08-28, at 12:39 PM, Justin Richer <jric...@mitre.org> >wrote: >>>> >>>>> The initial_access_token doesn't assume that it's from the local >domain. It merely assumes that the authorization server accepts the >token, which would be true in the UMA case due to the federation. It >could also be the exact same kinds of mechanisms that the software >statement would use to achieve federation. >>>>> >>>>> I still don't see how an auth server is going to know about a >client's configuration state with the assertion swap method, since >there's no defined mechanism for sending a JWT assertion to the >authorization endpoint. >>>>> >>>>> -- Justin >>>>> >>>>> On 08/28/2013 12:35 PM, Phil Hunt wrote: >>>>>> George, >>>>>> >>>>>> It would be reasonable for a client to submit an assertion, and >obtain its own client assertion in return. This is very close to what >is happening per 2.1, 2.2 of >http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06 >>>>>> >>>>>> In this case, the Software Statement is an authorization that is >exchanged for a client assertion in return. Then the clients >authenticate per section 2.2 of the JWT spec. >>>>>> >>>>>> Regarding initial_access_token. This does have some of the >characteristics I am speaking of. But it is unspecified and the >assumption is that it is issued by the local domain. This doesn't work >in the UMA case because that's more like a federated model. Thus the >specified software statement works because the AS can approve the >client software based on name, and/or developer, and/or publisher -- >whatever trust requires. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.h...@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2013-08-28, at 9:29 AM, George Fletcher <gffle...@aol.com> >wrote: >>>>>> >>>>>>> I can't say I understand what you mean by a simple assertion >swap... but if you are wanting to use a client_assertion flow instead >of the code flow then that's something completely different. If you are >saying that you want the client_id to represent an "instance" in a >stateless way using an "assertion" then that's already possible today. >>>>>>> >>>>>>> George >>>>>>> >>>>>>> On 8/28/13 12:23 PM, Phil Hunt wrote: >>>>>>>> George >>>>>>>> >>>>>>>> That case can be solved with a simple assertion swap. We just >have to profile it. >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On 2013-08-28, at 9:20, George Fletcher <gffle...@aol.com> >wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 8/28/13 12:02 PM, Phil Hunt wrote: >>>>>>>>>> Please define the all in one case. I think this is the edge >case and is in fact rare. >>>>>>>>>> >>>>>>>>>> I agree, in many cases step 1 can be made by simply approving >a class of software. But then step 2 is simplified. >>>>>>>>>> >>>>>>>>>> Dyn reg assumes every registration of an instance is unique >which too me is a very extreme >>>>>>>>> If you have a mobile app that needs to do the code flow... >which requires a client_secret in order to retrieve the access token >and refresh token, how does the app do this without per app instance >registration? >>>>>>>>> >>>>>>>>> I'd argue that almost all user facing mobile apps will want >the above flow and that's not a small, rare edge case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> George >>>>>>>>>> position. >>>>>>>>>> >>>>>>>>>> Phil >>>>>>>>>> >>>>>>>>>> On 2013-08-28, at 8:41, Justin Richer <jric...@mitre.org> >wrote: >>>>>>>>>> >>>>>>>>>>> Except for the cases where you want step 1 to happen in >band. To me, that is a vitally and fundamentally important use case >that we can't disregard, and we must have a solution that can >accommodate that. The notions of "publisher" and "product" fade very >quickly once you get outside of the software vendor world. >>>>>>>>>>> >>>>>>>>>>> This is, of course, not to stand in the way of other >solutions or approaches (such as something assertion based like you're >after). It's not a one-or-the-other proposition, especially when there >are mutually exclusive aspects of each. >>>>>>>>>>> >>>>>>>>>>> Therefore I once again call for the WG to finish the current >dynamic registration spec *AND* pursue the assertion based process that >Phil's talking about. They're not mutually exclusive, let's please stop >talking about them like they are. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On 08/28/2013 11:17 AM, Phil Hunt wrote: >>>>>>>>>>>> Sorry. I meant also to say i think there are 2 registration >steps. >>>>>>>>>>>> >>>>>>>>>>>> 1. Software registration/approval. This often happens out >of band. But in this step policy is defined that approves software for >use. Many of the reg params are known here. >>>>>>>>>>>> >>>>>>>>>>>> Federation techniques come into play as trust approvals can >be based on developer, product or even publisher. >>>>>>>>>>>> >>>>>>>>>>>> 2. Each instance associates in a stateless way. Only >clients that need credential rotation need more. >>>>>>>>>>>> >>>>>>>>>>>> Phil >>>>>>>>>>>> >>>>>>>>>>>> On 2013-08-28, at 8:04, Phil Hunt <phil.h...@oracle.com> >wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I have a conflict I cannot get out of for 2pacific. >>>>>>>>>>>>> >>>>>>>>>>>>> I think a certificate based approach is going to simplify >exchanges in all cases. I encourage the group to explore the concept on >the call. >>>>>>>>>>>>> >>>>>>>>>>>>> I am not sure breaking dyn reg up helps. It creates yet >another option. I would like to explore how federation concept in >software statements can help with facilitating association and making >many reg stateless. >>>>>>>>>>>>> >>>>>>>>>>>>> Phil >>>>>>>>>>>>> >>>>>>>>>>>>> On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - >FI/Espoo)" <hannes.tschofe...@nsn.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Here are the conference bridge / Webex details for the >call today. >>>>>>>>>>>>>> We are going to complete the use case discussions from >last time (Phil wasn't able to walk through all slides). Justin was >also able to work out a strawman proposal based on the discussions last >week and we will have a look at it to see whether this is a suitable >compromise. Here is Justin's mail, in case you have missed it: >http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> Phil, please feel free to make adjustments to your slides >given the Justin's recent proposal. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Topic: OAuth Dynamic Client Registration >>>>>>>>>>>>>> Date: Wednesday, August 28, 2013 >>>>>>>>>>>>>> Time: 2:00 pm, Pacific Daylight Time (San Francisco, >GMT-07:00) >>>>>>>>>>>>>> Meeting Number: 703 230 586 >>>>>>>>>>>>>> Meeting Password: oauth >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------- >>>>>>>>>>>>>> To join the online meeting >>>>>>>>>>>>>> ------------------------------------------------------- >>>>>>>>>>>>>> 1. Go to >https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0 >>>>>>>>>>>>>> 2. Enter your name and email address. >>>>>>>>>>>>>> 3. Enter the meeting password: oauth >>>>>>>>>>>>>> 4. Click "Join Now". >>>>>>>>>>>>>> >>>>>>>>>>>>>> To view in other time zones or languages, please click >the link: >>>>>>>>>>>>>> >https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&ORT=MiM0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> To add this meeting to your calendar program (for example >Microsoft Outlook), click this link: >>>>>>>>>>>>>> >https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=C6-AjLGvhdYjmpVdx75M6UsAwrNLMsequ5n95Gyv1R8=&RT=MiM0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------- >>>>>>>>>>>>>> To join the teleconference only >>>>>>>>>>>>>> ------------------------------------------------------- >>>>>>>>>>>>>> Global dial-in Numbers: >http://www.nokiasiemensnetworks.com/nvc >>>>>>>>>>>>>> Conference Code: 944 910 5485 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> <XeC> >>>>>>> >>>>>>> -- >>>>>>> <XeC.png> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> -- >> <XeC.png> > > > >------------------------------------------------------------------------ > >_______________________________________________ >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
