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>