I'd still like to see this proposed as a new I-D. It can be very short. I will
have the extensibility guidelines in the next draft or two, but you can start
by just declaring a new parameter for the relevant endpoints.
EHL
On 6/7/10 7:53 PM, "Nat Sakimura" wrote:
I fully agree on it.
Instea
The comment was about the token endpoint which used to include a 'type'
parameter (indicating the flow being used). All the flows share the same token
endpoint.
EHL
On 6/11/10 2:24 PM, "Christian Scholz" wrote:
Hi!
Am 11.06.10 22:47, schrieb Marius Scurtescu:
> On Fri, Jun 11, 2010 at 1:11
On 6/11/10 1:47 PM, "Marius Scurtescu" wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav
> wrote:
>> Draft -07 represents a major rearrangement of the document. I still have a
>> lot of work to do but wanted to share my progress and get some general
>> feedback. The draft includes a
It doesn't really. It is completely clear what kind of authorization grant the
client is providing simply by looking at the parameter. It might make the code
a few lines longer (a few if-else instead of a switch-case) but because these
are all post parameters, you access them the same way (i.e.
Hi!
Am 11.06.10 22:47, schrieb Marius Scurtescu:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav
> wrote:
>> Draft -07 represents a major rearrangement of the document. I still have a
>> lot of work to do but wanted to share my progress and get some general
>> feedback. The draft includes
I agree with Marius: I think we should keep the explicit flow name in
there (in the 'type' parameter or equivalent), as it (among other
things) opens the possibility for the rescope and revoke operations. It
makes it very clear how both client and server expect things to behave.
-- Justin
On Fri
+1
On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah wrote:
> +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard wrote:
>>
>> +1
>>
>> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
>>
>> > +1
>> >
>> > --
>> > James Manger
>> >
>> > --
>> > From: oauth-boun...@ietf.org [mailto:oauth-b
On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav wrote:
> Draft -07 represents a major rearrangement of the document. I still have a
> lot of work to do but wanted to share my progress and get some general
> feedback. The draft includes a few normative language changes but the main
> focus is
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
I'll let you know when I see the I-D :-)
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Friday, June 11, 2010 12:51 PM
> To: Eran Hammer-Lahav
> Cc: David Recordon; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] proposal: multiple access
A good question!
I suspect I know the problem here.
In mobile networks users are authenticated separately and for separate
purposes. So, one gets authenticated via MSISDN for the link layer
connection, with IMSI--for UMTS, with IMPI--for IMS. (All of these are
achieved by using the AKA protoc
Draft -07 represents a major rearrangement of the document. I still have a lot
of work to do but wanted to share my progress and get some general feedback.
The draft includes a few normative language changes but the main focus is on
the document structure and how the architecture is explained.
On 6/11/10 3:15 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher wrote:
On 6/11/10 2:09 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher
wrote:
Well... given this is a POST and structured data... it would be possib
Hi,
thanks for your advice. I described the new parameter in my proposal.
What additional text/information would you expect in an I-D?
regards,
Torsten.
Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav:
I strongly believe that it should be first presented as an I-D. This is true in
general fo
Hi Kevin,
what problems do you have with pre-paid users? Is your network unable to
authenticate them (by IMSI or MSISDN)?
regards,
Torsten.
Am 08.06.2010 18:31, schrieb Kevin Smith:
Hi David, Blaine,
We (the OneAPI group) have been looking further into OAUTH 2.0 and
would like to see how i
Hi Christian,
in my opinion, the token should be digitally signed in order to detect
modifications. HMAC-SHA256 or RSA are good candidates for that. If you
really need encryption depends on your privacy and security requirements.
Typical token contents are: issuer, validity/expiration, audien
On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher wrote:
> On 6/11/10 2:09 PM, Marius Scurtescu wrote:
>>
>> On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher
>> wrote:
>>
>>>
>>> On 6/11/10 12:34 PM, Marius Scurtescu wrote:
>>>
On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher
wro
+1 to re-delegation
I'd like to add that with down-scoping and re-delegation it would be
nice to be able to bind a re-delegated access token to the client that
will present it. With re-delegation, the down-stream client doesn't have
an easy "refresh" token so a short-lived access token might n
I'd like to voice support for Dick's proposal of re-scoping[1] and (in
later discussion) revoking access tokens using the refresh token as
authentication. I'd like to see us give clients a way to manipulate
tokens through OAuth entirely. I also think that revoke should be a
separate mechanism from
On 6/11/10 2:09 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher wrote:
On 6/11/10 12:34 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 9:25 AM, George Fletcherwrote:
On 6/11/10 12:07 PM, Marius Scurtescu wrote:
On Fri, Jun
On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher wrote:
> On 6/11/10 12:34 PM, Marius Scurtescu wrote:
>>
>> On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher wrote:
>>
>>>
>>> On 6/11/10 12:07 PM, Marius Scurtescu wrote:
>>>
On Fri, Jun 11, 2010 at 8:59 AM, David Recordon
wrote:
Client doesn't need to *be* a web server, just *have* a web server available.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of George Fletcher
> Sent: Friday, June 11, 2010 9:25 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] User-ag
I'm 135 messages behind on the list. I'm knee deep in -07.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, June 11, 2010 10:03 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Fwd: Re: [OAUTH-WG] in-app logout?
Hi Eran,
you probably didn't notice my p
On 6/11/10 12:34 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher wrote:
On 6/11/10 12:07 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 8:59 AM, David Recordon
wrote:
That sounds like a security consideration to me! :)
I imagine that aut
Hi Eran,
you probably didn't notice my posting. What do you think about adding a
revocation request to the spec?
regards,
Torsten.
Original-Nachricht
Betreff:Re: [OAUTH-WG] in-app logout?
Datum: Wed, 26 May 2010 20:26:18 +0200
Von:Torsten Lodderstedt
An: Er
On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher wrote:
> On 6/11/10 12:07 PM, Marius Scurtescu wrote:
>>
>> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon
>> wrote:
>>
>>>
>>> That sounds like a security consideration to me! :)
>>>
>>> I imagine that authorization servers will verify ownership
On 6/11/10 12:07 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 8:59 AM, David Recordon wrote:
That sounds like a security consideration to me! :)
I imagine that authorization servers will verify ownership in
different manners depending on their tolerance of risk.
Instead of PO
On Fri, Jun 11, 2010 at 8:59 AM, David Recordon wrote:
> That sounds like a security consideration to me! :)
>
> I imagine that authorization servers will verify ownership in
> different manners depending on their tolerance of risk.
Instead of POSTing a JSON with all the details, dynamic binding
Cool, want to take a stab at the security considerations section of
this? #1 and #2 feel like they fit there.
I agree with #3 being nice, but without an API wouldn't you make an
immediate mode request, see that it failed, and then make a normal
request?
--David
On Fri, Jun 11, 2010 at 8:59 AM,
Hi David,
Thanks a lot for writing this up! Some feedback:
1) If the user is required to enter their credentials (aka their password),
the UI must be displayed in an independent browser window (not in an inlined
iframe), with the address bar displayed. The AS must return framebusting JS
code to e
That sounds like a security consideration to me! :)
I imagine that authorization servers will verify ownership in
different manners depending on their tolerance of risk.
On Fri, Jun 11, 2010 at 8:54 AM, Marius Scurtescu wrote:
> On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz wrote:
>> Hi!
>
On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz wrote:
> Hi!
>
> Am 11.06.10 17:05, schrieb Justin Richer:
>> Along these lines, I'd like to propose an extension for per-client
>> instance information to be passed from a client to the server. Things
>> like a human-readable client name/descripti
One missing point from this is that the same client ID could be used for
different instances for the same user. That's how google's
xoauth_display_name was used, and that's what I'm proposing as an
extension to the capability below. Unregistered clients are a separate,
but slightly related, issue,
+1 for "dynamic registration"
On 6/11/10 11:35 AM, Christian Scholz wrote:
Hi!
Am 11.06.10 17:05, schrieb Justin Richer:
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client nam
I am in favor of an optional client_name parameter. I think a client_id
parameter of the form of an HTTP URL, effecttively reserving the prefix http://
would be sufficient to indicate an unregistered client ID. The URL could then
point to either a favicon type image or an XML doc more fully de
Hi!
Am 11.06.10 17:05, schrieb Justin Richer:
> Along these lines, I'd like to propose an extension for per-client
> instance information to be passed from a client to the server. Things
> like a human-readable client name/description, instance name/description
> (could be tied to host name, ip, l
Unlike the rest of the flows, the device flow lacks deployment experience and
is still likely to change. It also uses a very different architecture than the
rest of the flows (which becomes more obvious in my -07 rewrite). Unless there
is strong objection, I am going to remove it from the core s
On Fri, Jun 11, 2010 at 8:05 AM, Justin Richer wrote:
> Along these lines, I'd like to propose an extension for per-client
> instance information to be passed from a client to the server. Things
> like a human-readable client name/description, instance name/description
> (could be tied to host nam
I think username needs to be covered in the OpenID Connect spec (i.e. Identity
layer on top of OAuth). Just a hint isn't enough. The client needs to be able
to verify that the server response is what was asked, and also the server needs
to inform the client of who logged in.
EHL
On 6/11/10 6:
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client name/description, instance name/description
(could be tied to host name, ip, label like "home" or "Work"), and even
something like a
Am 11.06.2010 16:38, schrieb George Fletcher:
Makes perfect sense as we have the same model for our clients & tokens:)
The one use case we've encountered is that this model revokes the
tokens for all clients with the same client_id. So if I've got three
of the same client installed (on three
Makes perfect sense as we have the same model for our clients & tokens:)
The one use case we've encountered is that this model revokes the tokens
for all clients with the same client_id. So if I've got three of the
same client installed (on three computers) and they likely all have the
same cl
There was discussion about a username hint parameter, in general this
is needed when immediate is used. Should username go to this UX
Extension, or rather immediate and username should go to a separate
one together?
Marius
On Thu, Jun 10, 2010 at 5:32 PM, David Recordon wrote:
> +1 for moving
Unlike the rest of the flows, the device flow lacks deployment experience and
is still likely to change. It also uses a very different architecture than the
rest of the flows (which becomes more obvious in my -07 rewrite). Unless there
is strong objection, I am going to remove it from the core s
44 matches
Mail list logo
