The initial_access_token doesn't assume that it's from the local domain.
It merely assumes that the authorization server accepts the token, which
would be true in the UMA case due to the federation. It could also be
the exact same kinds of mechanisms that the software statement would use
to achieve federation.
I still don't see how an auth server is going to know about a client's
configuration state with the assertion swap method, since there's no
defined mechanism for sending a JWT assertion to the authorization
endpoint.
-- Justin
On 08/28/2013 12:35 PM, Phil Hunt wrote:
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 <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On 2013-08-28, at 9:29 AM, George Fletcher <gffle...@aol.com
<mailto: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
<mailto: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
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
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> <http://connect.me/gffletch>
--
<XeC.png> <http://connect.me/gffletch>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
