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 assumptions, mind you) are baked into what the spec
does and how it works. From what I understand of how SCIM works, you'd
have to jump through some interesting hoops to get to the self-managed
registration using SCIM as it's defined today, or even as it could be
defined. There are profiles of using SCIM to transfer information about
registered clients between AS's in different security domains (or
different instances), but that's not dynamic registration. Someone can
feel free to correct me if I'm completely off the rails here. (Won't be
the first time. :) )
I say let's just keep letting SCIM be good at what it's good at and not
try to squish it into something it's not.
-- Justin
On 05/22/2013 02:46 PM, Phil Hunt wrote:
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
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On 2013-05-22, at 11:39 AM, Anthony Nadalin wrote:
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 [mailto:jric...@mitre.org]
*Sent:*Monday, May 20, 2013 11:10 AM
*To:*Anthony Nadalin
*Cc:*Phil Hunt; oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
Tony, can you be more specific? What needs to be changed in your
opinion? What text changes would you suggest?
-- Justin
On 05/20/2013 02:09 PM, Anthony Nadalin wrote:
Agree
*From:*oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>[mailto:oauth-boun...@ietf.org]*On
Behalf Of*Phil Hunt
*Sent:*Monday, May 20, 2013 9:42 AM
*To:*Justin Richer
*Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic
Registration
This draft isn't ready for LC.
Phil
On 2013-05-20, at 8:49, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
But also keep in mind that this is last-call, and that we
don't really want to encourage avoidable drastic changes at
this stage.
-- Justin
On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming.
The issue is that new developers can't figure out what
token is being referred to.
Phil
On 2013-05-20, at 8:09, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
Phil Hunt's review of the Dynamic Registration
specification has raised a couple of issues that I
felt were getting buried by the larger discussion
(which I still strongly encourage others to jump in
to). Namely, Phil has suggested a couple of syntax
changes to the names of several parameters.
1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method ->
token_endpoint_client_auth_method
I'd like to get a feeling,*especially from
developers*who have deployed this draft spec, what we
ought to do for each of these:
A) Keep the parameter names as-is
B) Adopt the new names as above
C) Adopt a new name that I will specify
In all cases, clarifying text will be added to the
parameter *definitions* so that it's more clear to
people reading the spec what each piece does.
Speaking as the editor: "A" is the default as far as
I'm concerned, since we shouldn't change syntax
without very good reason to do so. That said, if it's
going to be better for developers with the new
parameter names, I am open to fixing them now.
Naming things is hard.
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
