n 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
>>>>&
mer 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 th
@ietf.org] *On
Behalf Of *Anthony Nadalin
*Sent:* Wednesday, January 30, 2013 1:38 PM
*To:* Justin Richer; Shiu Fun Poon
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
I would not say that this is incompatible with OAUTH at all , as OAUTH
has a physical and logical
nightmare were we had to have separate services, nuts
*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Wednesday, January 30, 2013 7:20 AM
*To:* Shiu Fun Poon
*Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
<mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Concerning OAuth introspectio
not RESTful in a
strict sense of the term. It doesn’t seem to be a problem in practice.
-- Mike
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Anthony Nadalin
*Sent:* Wednesday, January 30, 2013 1:38 PM
*To:* Justin Richer; Shiu Fun Poon
*Cc:* oauth@ietf.org
*Subject:* Re: [O
l endpoints. We had to live through the Web
> Service endpoint nightmare were we had to have separate services, nuts
>
> *From:*Justin Richer [mailto:jric...@mitre.org]
> *Sent:* Wednesday, January 30, 2013 7:20 AM
> *To:* Shiu Fun Poon
> *Cc:* Anthony Nadalin; Nat Sakimu
Of
Anthony Nadalin
Sent: Wednesday, January 30, 2013 1:38 PM
To: Justin Richer; Shiu Fun Poon
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
I would not say that this is incompatible with OAUTH at all , as OAUTH has a
physical and logical endpoints. We had to live
:20 AM
To: Shiu Fun Poon
Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Hi.. Tony.. You are able to present this better than I do.
Justin,
Currently as it is, the spec is unflexible. So when I send a request to an
endpoint, the endpoint
-- 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,
ngs the way they are.
-- 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
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 Sak
e
>>> 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
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.
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 th
Well, you *can* have it both ways. But to your point Justin - what's the
value in it? Allowing for both adds a bunch of unnecessary complexity while
only adding flexibility for the sake of flexibility with no tangible
benefit.
On Thu, Jan 24, 2013 at 7:26 AM, Justin Richer wrote:
>
> On 01/24/20
uary 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. Registra
.
+1
-- Todd
From:Eve Maler
To:Sergey Beryozkin,
Cc:Paul Bryan,"oauth@ietf.org WG"
Date: 01/23/2013 12:18 PM
Subject:Re: [OAUTH-WG] Concerning OAuth introspection
Sent by:oauth-boun...@ietf.org
Agreed that REST purity may come at a
in
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 m
From:Eve Maler
To:Sergey Beryozkin ,
Cc:Paul Bryan , "oauth@ietf.org WG"
Date: 01/23/2013 12:18 PM
Subject:Re: [OAUTH-WG] Concerning OAuth introspection
Sent by:oauth-boun...@ietf.org
Agreed that REST purity may come at a cost that'
hole
>> > picture.
>>
>> +1
>>
>> -- Todd
>>
>>
>>
>>
>>
>>
>>
>> From: Eve Maler
>> To:Sergey Beryozkin ,
>> Cc:Paul Bryan , "oauth@ietf.org WG"
>>
rom:Eve Maler
> To:Sergey Beryozkin ,
> Cc:Paul Bryan , "oauth@ietf.org WG"
>
> Date:01/23/2013 12:18 PM
> Subject:Re: [OAUTH-WG] Concerning OAuth introspection
> Sent by:oauth-boun...@ietf.org
>
>
>
> A
o: Sergey Beryozkin ,
Cc: Paul Bryan , "oauth@ietf.org WG"
Date: 01/23/2013 12:18 PM
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Sent by:oauth-boun...@ietf.org
Agreed that REST purity may come at a cost that's too high. On the other
hand, it&#
day, 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 sa
e.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 pa
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 reall
;> 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
t;> 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 S
xibility 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
>
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 predi
] 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
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:
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 you
] 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
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 cut
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 clean
For the client_id, if there is no client_secret, how is that
information going to flow thru ? In the oauth spec, the protocol
allows you to specify the client_id and secret in the payload. So it
would be good for this spec to follow as closely to the oauth spec,
that will be great.
The id
"Action" goes against REST principle.
I do not think it is a good idea.
=nat via iPhone
Jan 23, 2013 4:00、Justin Richer のメッセージ:
> (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 ea
(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 itsel
38 matches
Mail list logo
