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
On 23/01/13 15:47, Justin Richer wrote:
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
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]
Agreed that REST purity may come at a cost that's too high. On the other hand,
it's a useful exercise to imagine how much more benefit could potentially be
gotten for free if we look at it through a pure-REST lens, not just with
what's already been specified but the whole picture.
If what
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
FWIW, some of us have made a proposal for exactly this type of standardized
AS/RS communication:
http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
The UMA profile refers normatively to this spec, and at that higher
profile-specific level, it has an extensive set of AS
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
Tony took the words right out of my mouth. :-) Or, at least, the moment someone
expresses an actual need for the next piece of flexibility (beyond Wouldn't it
be cool if...* to I have a customer that needs...), you're on the slope
towards maybe benefiting from enabling more and more of the HTTP
Rudely responding to myself: I'm not saying this approach should definitely be
taken, just that it's a good idea to spend 15 minutes looking at the benefits
and downsides of it vs. the current laser-focus approach.
Eve
On 23 Jan 2013, at 9:28 AM, Eve Maler e...@xmlgrrl.com wrote:
But it's already not a fully RESTful setup, and it's not really meant to
be as it stands. I realize that's how the original UMA registration spec
did things, but the rest of OAuth doesn't work that way. I would rather
it be parallel with the rest of the framework, all ideals aside.
Which brings
No, we want one endpoint. Keep it simple.
From: Justin Richer
Sent: 1/23/2013 9:31 AM
To: Eve Maler
Cc: Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
But it's already not a fully RESTful setup, and it's not really meant to
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]
I am very confused, and I need someone to explain to me what I am
missing. Why won't it work to just pick one? What are people already
stuck with that this would affect? It's not like we're trying to unseat
a well-established protocol with a wide installation base here.
How will giving people the
On the other hand, it's a useful exercise to imagine how much more
benefit could potentially be gotten for free if we look at it through a
pure-REST lens, not just with what's already been specified but the whole
picture.
+1
-- Todd
From: Eve Maler e...@xmlgrrl.com
To: Sergey
My understanding is OAuth is an HTTP protocol. It is not intended to be REST
specific or by implication be RESTful.
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote:
On the other hand, it's a useful exercise to imagine how much
I've defined a new response_type for the authorization endpoint for
dealing with sessions - call it urn:example:session_code. Am I required
to also include that value in the response as the code identifier, as in
(unencoded):
I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot view). To
the extent that it, or its constituent parts, defines endpoints, it also is a
security API or set of APIs (10,000-foot view). Since its endpoints use HTTP,
this gives the opportunity to ask the question: how RESTful
While Eve is right in principle, I think it's better for everyone if
things remain consistent across different endpoints where possible. This
is why registration now does form input and json output, for instance.
Still simple, not as RESTy, but ultimately REST-friendly, which is all
OAuth ever
Nice suggestion! Good point that both the RS and the client, respectively, have
ways (illustrated by a combination of dyn-client-reg and resource-set-reg) to
review/indicate abilities and preferences in engaging with the AS.
Eve
On 23 Jan 2013, at 10:05 AM, George Fletcher
Review:
1. Since not stated I assume that the Revocation Endpoint can exist on a
different server from the Authorization server (or is it assumed that they are
1), if so how is the Revocation Endpoint found?
2. Any token type that is supported can be revoked, including refresh
20 matches
Mail list logo
