Yes. A client could pass the software statement *directly* as its client credential. Which is one of the *simple* solutions. 8-)
The other case is where the client instance needs its own credential as George indicates. In that case it could swap the statement for a unique client assertion. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-28, at 9:38 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > On 28/08/13 17:33, George Fletcher wrote: >> So I understand that you'd rather that OAuth doesn't require a >> client_secret and that's fine. However, I don't think we should impose >> that thinking on the rest of the world who have already implemented it >> and have it working and scaling without issues. If the core of this >> discussion is around replacing client_id and client_secret with a >> client_assertion then lets have that discussion separately and not bury >> it in the dynamic registration discussion. >> >> Could you not profile OAuth2 to support a flow that allows for retrieval >> of access and refresh tokens using code + client_assertion? Doesn't seem >> like that hard a profile and then the rest of this could fall out pretty >> easily. >> > That is already supported AFAIK, something like > > grant_type=authorization_code > &code=12345678 > &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Asaml2-bearer > &client_assertion=Base64UrlEncoded-SAML2-Bearer-Assertion > > probably the same works with JWT > > Sergey > > >> Thanks, >> George >> >> On 8/28/13 12:28 PM, Anthony Nadalin wrote: >>> >>> I do think that this is the rare-edge use case, we would not want >>> require client-secret, we already have that mess today with OAuth and >>> trying not to continue the proliferation, we solve this today with our >>> STS and assertion swaps/transformations, it scales, performs and we >>> don’t have the management debacle this specification creates >>> >>> *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On >>> Behalf Of *George Fletcher >>> *Sent:* Wednesday, August 28, 2013 9:21 AM >>> *To:* Phil Hunt >>> *Cc:* oauth mailing list >>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conference Call: >>> Wed 28 Aug, 2pm PDT: Conference Bridge Details >>> >>> 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> >>> <mailto: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> >>> <mailto: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> <mailto: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 >>> tohttps://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 <mailto:OAuth@ietf.org> >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> -- >>> George Fletcher <http://connect.me/gffletch> >>> >> >> -- >> George Fletcher <http://connect.me/gffletch> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com > _______________________________________________ > 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
