Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

[Phil Hunt <[e-mail]>]

So why are you fighting so hard against standardizing software assertions?  You're affectively already using the solution for BB+.  

The fact that a standardized initial_access_token eliminates most of the registration endpoint seems to be your primary objection.

Phil

@independentid
www.independentid.com
[e-mail]







On 2013-08-28, at 9:41 AM, Justin Richer <[e-mail]> wrote:

> Yes, that already works. And you could accomplish that with the current dynamic registration spec, too -- it's just that client assertions were deemed too-underspecified to include in the base draft, and nobody's stepped up to offer a full writeup and extension of using other auth mechanisms (outside of OpenID Connect).
> 
> -- Justin
> 
> On 08/28/2013 12:38 PM, Sergey Beryozkin 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:*[e-mail] [mailto:[e-mail]] *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<[e-mail]> <mailto:[e-mail]>  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<[e-mail]> <mailto:[e-mail]>  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)"<[e-mail]> <mailto:[e-mail]>  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
>>>> 
>>>>                    [e-mail] <mailto:[e-mail]>
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> 
>>>>                OAuth mailing list
>>>> 
>>>>                [e-mail]  <mailto:[e-mail]>
>>>> 
>>>>                https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>>            _______________________________________________
>>>> 
>>>>            OAuth mailing list
>>>> 
>>>>            [e-mail]  <mailto:[e-mail]>
>>>> 
>>>>            https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 
>>>>    _______________________________________________
>>>> 
>>>>    OAuth mailing list
>>>> 
>>>>    [e-mail]  <mailto:[e-mail]>
>>>> 
>>>>    https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> George Fletcher <http://connect.me/gffletch>
>>>> 
>>> 
>>> -- 
>>> George Fletcher <http://connect.me/gffletch>
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth