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
