I'm not emphatic about either, but my vote is to remove the envelope.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Monday, June 21, 2010 9:49 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
O
I like the idea of simplifying the core spec, but the devil is in the details.
In practice it seems onerous to ask the AS and the PR to know both the key used
to sign the token as well as the key used to sign the request (regardless of if
the request signing key is the same as the client_secret)
Piling on: +1 for #3.
--justin
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Pelle
Braendgaard
Sent: Friday, April 30, 2010 2:13 PM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
+1 for #3
Since google
value in the 401 (should the URI reference the
individual service or the bundle).
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Thursday, April 15, 2010 9:44 PM
To: Justin Smith; OAuth WG
Subject: RE: [OAUTH-WG] Issue: Scope parameter
> So, let’s say there is an Authorizat
token
request to http://as.com. Is that right?
If so, then how does http://as.com know that the intended resource is
http://foo.com?
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Thursday, April 15, 2010 9:09 PM
To: Justin Smith; OAuth WG
Subject: RE: [OAUTH-WG] Issue
rom: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Smith
Sent: Friday, 16 April 2010 9:39 AM
To: Eran Hammer-Lahav; Marius Scurtescu; record...@gmail.com
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter
I don’t see how the presence of a scope parameter hu
I don't see how the presence of a scope parameter hurts interoperability.
It think scope needs to be a 1st class citizen in the spec, not an extension.
Without it, a client cannot request access to a specific set of resources
(whether its represented as a string, URI, or anything else). Does the
> I don't see why an opaque scope parameter would create any problems
> for a library implementation. Working on such an implementation right
> now and opaque scopes are perfectly fine.
I completely agree. In practice this hasn't caused a problem. We discussed the
idea of forcing an absolute URI
Eran,
Good progress. A few comments below:
Sec. 2.2. Flow Parameters:
Comment 1: The recommendation to keep access tokens less than 255 chars seems
bizarre. I'd like to remove it entirely. Previous threads have discussed this.
General comment on the flows:
Comment 2: The scope parameter (from
+1
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Marius Scurtescu
Sent: Tuesday, March 30, 2010 12:07 PM
To: Brian Eaton
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] two username/password profiles
This must be an editing error.
Version 0.9.7.
Along those lines, here's an access token (SWT w/o URL encoding) that has some
role and attribute data. I think it is representative of how customers are
using the OAuth WRAP implementation in AppFabric.
Role=user,superuser,administrator&Action=create,retrieve,update,delete&CustomerID=123456789&
Yep - mistake on my part. I the discussion was around section 5.1 and 5.2 on
OAuth WRAP v0.9.7.2.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Tuesday, March 09, 2010 9:46 AM
To: oauth-wrap...@googlegroups.com; oauth@ie
Part of the motivation behind that profile was to allow an autonomous client
(no end-user identity passed to the AS) the ability to access a web service. In
that case, I don't see what the client secret (along with the username and
password) would be adding.
Ethan - assuming the token is signed
During the last call I volunteered to write a use case that warrants message
signing. After thinking about the problem for a bit, it is no longer abundantly
clear to me that message signing needs to be addressed in OAuth (clearly
signing a token is a different story).
However, here's the use c
14 matches
Mail list logo
