Hi Phil,
You would send the client's credential to the authz endpoint, so it would go through the browser and would be exposed to other parties. I agree with George and others. This is a topic different from dyn reg and should be handled independently. I personally consider assertions as means to client authentication an interesting option we should further evaluate. But this would be an evolution to OAuth itself. regards, Torsten. Phil Hunt <phil.h...@oracle.com> schrieb: >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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
