On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
I like this most, would rename it to say
/oauth/client/registration
or
/oauth/client-registration
etc
and reword the spec such that it will let those who implement do it
with one endpoint or many, whatever is preferred
That's the whole point of this discussion -- I don't believe you can
have it both ways.
In one way, you say there are three endpoints and, if you're keeping
with the rest of OAuth, you don't give them official URL patterns that
they must follow. How the client gets those endpoints is up to discovery
or configuration, but the client has an internal map from each bit of
functionality to a particular URL that's specific to the service, much
in the same way that the client today has to map the authorization and
token endpoints. In the other method, you've got one endpoint that the
client sends a well-defined parameter to in order to accomplish the same
goal.
So if you allow both at once, does a client send the "operation"
parameter or not? Is it looking for one url or three to store in its
configuration? I don't think this level of flexibility buys you anything
useful, and I strongly believe that it will deeply hurt the
functionality of dynamic registration if it's allowed.
As it stands today, you can still make the URL whatever you want. If we
went with three endpoints you could also make those URLs whatever you
wanted. Nobody has yet pointed out to me what the actual benefit is of
making both valid.
I personally prefer the method of three endpoint URLs because it's
cleaner and semantically equivalent, but I am hesitant to change that
behavior unless there's strong working group support for it. I haven't
seen real support for it yet -- it's not a good call to make it fully
RESTful, and it's not a good call to leave it undefined. A client MUST
have a very clear recipe of what to do on startup for this to work in
the wild.
-- Justin
help multitenancy? How does it even affect that use case? Consider that
the base URL for all of these is completely up to the host environment
(nothing is bound to the root URL). Consider that clients still have to
know what the URL (or URLs) are, in either case. Consider that clients
still need to know how to manage all the parameters and responses.
If anything, keeping it the way that it is with a single URL could be
argued to help multitenancy because setting up routing to multiple URL
endpoints can sometimes be problematic in hosted environments. However,
OAuth already defines a bunch of endpoints, and we have to define at
least one more with this extension, so I'm not convinced that having
three with specific functions is really any different from having one
with three functions from a development, deployment, and implementation
perspective. I can tell you from experience that in our own server code,
the difference is trivial. (And from OAuth1 experience, you can always
have a query parameter as part of your endpoint URL if you need to. You
might hate yourself for doing it that way, but nothing says your base
URL can't already have parameters on it. A client just needs to know how
to appropriately tack its parameters onto an existing URL, and any HTTP
client worth its salt will know how to augment a query parameter set
with new items.)
The *real* difference between the two approaches is a philosophical
design one. The former overloads one URL with multiple functions
switched by a flag, the latter uses the URL itself as an implicit flag.
Under the hood, these could (and in many cases will) be all served by
the same chunks of code. The only difference is how this switch in
functionality is presented.
With that said, can somebody please explain to me how allowing *both* of
these as options simultaneously (what I understand Tony to be
suggesting) is a good idea, or how multitenancy even comes into play?
Because I am completely not seeing how these are related.
Thanks,
-- Justin
On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
It will not work the way you have it, as people do multi-tendency
different and they are already stuck with the method that they have
chosen, so they need the flexability, to restrict this is nuts as
people won't use it.
-----Original Message-----
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
I completely disagree with this assessment. Multi-tenancy will work
just fine (or even better) if everyone uses the same pattern.
Telling someone "it might be three different urls or it might be all
one url with a parameter" is just asking for a complete disaster.
What does the flexibility of allowing two approaches actually
accomplish?
You can argue about the merits of either approach, but having both
as unspecified options for registration, which is meant to help
things get going in a cold-boot environment, is just plain nuts.
-- Justin
On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
Registration has to work in a multi-tenant environment so flexibility
is needed
-----Original Message-----
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Because then nobody would know how to actually use the thing.
In my opinion, this is a key place where this kind of flexibility
is a very bad thing. Registration needs to work one fairly
predictable way.
-- Justin
On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
Why not just have a physical and logical endpoint options
-----Original Message-----
From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon;oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Which brings up an interesting question for the Registration doc:
right now, it's set up as a single endpoint with three operations.
We could instead define three endpoints for the different operations.
I've not been keen to make that deep of a cutting change to it,
but it would certainly be cleaner and more RESTful API design.
What do others think?
-- Justin
On 01/22/2013 08:05 PM, Nat Sakimura wrote:
"Action" goes against REST principle.
I do not think it is a good idea.
=nat via iPhone
Jan 23, 2013 4:00、Justin Richer<jric...@mitre.org> のメッセージ:
(CC'ing the working group)
I'm not sure what the "action/operation" flag would accomplish.
The idea behind having different endpoints in OAuth is that they
each do different kinds of things. The only "action/operation"
that I had envisioned for the introspection endpoint is
introspection itself: "I have a token, what does it mean?"
Note that client_id and client_secret *can* already be used at
this endpoint if the server supports that as part of their
client credentials setup. The examples use HTTP Basic with
client id and secret right now. Basically, the client can
authenticate however it wants, including any of the methods that
OAuth2 allows on the token endpoint. It could also authenticate
with an access token. At least, that's the intent of the
introspection draft -- if that's unclear, I'd be happy to accept
suggested changes to clarify this text.
-- Justin
On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
Justin,
This spec is looking good..
One thing I would like to recommend is to add "action"/"operation"
to the request. (and potentially add client_id and client_secret)
So the request will be like :
token REQUIRED
operation (wording to be determine) OPTIONAL inquire (default)
| revoke ...
resource_id OPTIONAL
client_id OPTIONAL
client_secret OPTIONAL
And for the OAuth client information, it should be an optional
parameter (in case it is a public client or client is
authenticated with SSL mutual authentication).
Please consider.
ShiuFun
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
