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
