Nit: section 2.1, under token type hint, the word parameter is
repeated.
Otherwise a quick read through looks good to me.
-- Justin
On 05/19/2013 01:07 PM, Torsten Lodderstedt wrote:
Hi all,
this revision covers all minor issues from IETF LC.
regards,
Torsten.
Am 19.05.2013 19:04,
Coming in late to this thread: I agree broadly with Justin, Mike, and John.
Having an in-band just-in-time registration capability is valuable. By analogy
with user identifiers, it's useful for client identifiers to be issued for the
asking as the first rung of an assurance (real-world
Speaking as an implementor, I'm actually in favor of changing
expires_at and issued_at to the values proposed below. It would
require some minor code changes on my end, but the impact would be
minimal, and I think that the new names are *much* more clear to new
developers. I think it will save
I'm neutral with changing (1) and (2) because they're not highly breaking
changes. These are optional parameters and code already has to be prepared to
not receive them and to ignore not understood parameters. If the change is
made, the result would be that existing implementations wouldn't
+1
I also agree with Justin's comment on token_endpoint_auth_method.
Never-the-less, I did want to pass along the feedback that some were confused.
The expires_at, issued_at thing though is particularly confusing (though the
text may be clear) and is a higher priority issue in my opinion.
So, I really don’t understand why dynamic registration is in scope, I
understand this relative to OpenID Connect but not OAuth, if this is indeed in
scope then I would have expected that the endpoint be based upon SCIM and not
something else like what has been done here.
From: Justin Richer
Let's make a new thread for this. It is worth some discussion.
We have some strong cases for this, and I do think dyn reg involves some
credential management issues that SCIM doesn't yet handle.
I think Justin is planning to make these aspects more clear in the draft.
Phil
@independentid
I had a conversation with Justin yesterday to try to come to a resolution
regarding my concerns about client instances and being able to associate client
instances that are issued for the same client software. I think we made some
progress.
Background:
In RFC6749, public clients, had a
I'm not sure why you don't think it's in scope, it's in the working
group's charter:
http://www.ietf.org/dyn/wg/charter/oauth-charter.html
So ... it's definitely in scope, and has been for over a year and a
half. This is the tenth version of this document-- an IETF Working Group
document
I answered some of this in my reply to Tony already, but from my
perspective it boils down to SCIM not really being that great of a fit
for this kind of use. It makes very different assumptions about who's
undertaking all of the actions, and those assumptions (which are
completely valid
Phil,
As I pointed out in the other thread, redirect_uri is the thing that ties
together the clients as that is the place the responses need to go to so is
hard to fake.
All instances of a particular client application will share the same
redirect_uri across all instances.
Adding a bunch
I totally disagree with your characterization of SCIM, while it can be used
from server to server (provision one system to another) it can also be client
to endpoint (initial provisioning and JIT provisioning). SCIM is fairly simple
(but can be complex), I also have concerns about SCIM not
+1
We already have a software_id field and it's named redirect_uris.
This doesn't seem well thought-out. We shouldn't try to jam it into the spec
at the last minute.
The good news is that since the registration spec allows for extensions, and
the proposed fields are optional, these could be
I'm having trouble understanding
We already have OAuth doing dynamic registration, I don’t think there is a
need to force it into OAuth.
I would be open to a scim dyn reg version. Particularly to discuss instance
metadata mgt which scim is good at and the credential managemenr/bootstrap
My mistake, was to say, We already have OpenID Connect doing dynamic
registration, I don’t think there is a need to force it into OAuth.
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Wednesday, May 22, 2013 3:16 PM
To: Anthony Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re:
In fact, one of the driving factors in this draft was so that OIDC and
UMA wouldn't have to invent their own protocols and that we could
abstract the knowledge in both of these for a well-considered basic use
case. We as a working group long ago agreed that we needed to do dynamic
registration
I agree that any new field or fields should be defined once the requirements
and flows are well-specified and well-understood as part of a complete
specification for those flows and use cases.
-- Mike
From: oauth-boun...@ietf.org
17 matches
Mail list logo
