On 30/01/13 16:42, Mike Jones wrote:
I believe that what we have now - a single endpoint with an "operation"
parameter, is more natural than having a different endpoint per operation. In all
likelihood, the implementation of all the operations (client_register, client_update, and
rotate_secret) would end up going through the same code path anyway, using an operation
parameter. So let's just keep expressing it that way on the wire too.
Having to maintain and register many endpoints for one logical set of
functionality would just make things harder in a practical sense. Let's leave
things the way they are.
For whatever it is worth: -1 to using operation parameters;
honestly I haven't thought, with my WS experience, that I will
contribute to this discussion :-), but "/oauth?operation=register" or
similar will just get REST gurus having a lot of criticism on it, it
won't of course the implementers from supporting it but this will just
distract many people from adopting OAuth2, this minor fact alone, when
all start saying, look, in OAuth2 they use query parameters as actions...
Just my 2c, Sergey
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Wednesday, January 30, 2013 8:18 AM
To: John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
On 01/30/2013 10:55 AM, John Bradley wrote:
My feeling was that letting the registration endpoint be a single URL (any url)
and using query paramaters was easer for servers and clients.
Saying take the base URI for the registration endpoint and append these paths
to it to do different operations seems more likely to go wrong fro developers.
Right, and to clarify, this isn't what I was saying. The spec wouldn't specify
the path at all, just say that they're three different endpoint URLs. The same
way that we specify that the auth endpoint and token endpoint are different
URLs.
I think my example might have been misleading. The URLs could just as easily be:
client_register -> /register_a_new_client rotate_secret ->
/client/go_get_a_secret_or_something
client_update-> /maintenance/update_client_information
Allowing both bath and query parameters is the worst option.
I am sympathetic with using POST and PUT and perhaps GET but I worry about
OAuth developers not getting it.
I also don't get Tony's point about multi tenancy. If each tenant can have
there own registration endpoint I don't see a problem beyond finding the
endpoint and that is what we have WF for.
Exactly. And to Bill's point in another thread, we could also register a link
type for each endpoint to help facilitate discovery:
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
-- Justin
John B.
On 2013-01-24, at 11:26 AM, Justin Richer<jric...@mitre.org> wrote:
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
_______________________________________________
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
