For the last time, I am not against standardizing software assertions. I have no idea where you keep getting that idea from, considering how many times I've publicly come out in support of it. I've even offered to help edit a spec to bring the ideas to their full and proper fruition.

What I disagree with is your conjecture that it eliminates the registration and configuration endpoints. It just doesn't, and they can work together fine.

Why are you fighting so hard against use cases that can't use or don't need software assertions?

 -- Justin

On 08/28/2013 12:43 PM, Phil Hunt wrote:
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
phil.h...@oracle.com







On 2013-08-28, at 9:41 AM, Justin Richer <jric...@mitre.org> 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:*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


_______________________________________________
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

Reply via email to