Hi Hannes,
as far as I understand, your proposal prevents adversaries to create new
requests utilizing a stolen access token. Does the proposal also intend to
prevent request replay?
Regards,
Torsten.
Am 16.07.2012 um 20:07 schrieb Hannes Tschofenig hannes.tschofe...@gmx.net:
Hi all,
I
Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec, which doesn't unnessarily restricts
implementations. OAuth leaves so much freedom to implementors (for
+1
Am 27.12.2012 um 02:43 schrieb Mike Jones michael.jo...@microsoft.com:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1
currently says:
Audience A URI that identifies the party intended to process the
assertion. The audience SHOULD be the URL of the
sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:
Hi all,
any other opinion regarding having or not having a token type parameter?
I would like to go with #1 as it is rather late in the process to
(re-)introduce a mandatory parameter. And making it an optional
parameter (#4) seems not really
Hi again,
On 27/12/12 09:41, Sergey Beryozkin wrote:
Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec, which doesn't unnessarily restricts
Agreed.
We need to clarify that the value of the audience claim can be multi valued as
well.
John B.
On 2012-12-26, at 10:43 PM, Mike Jones michael.jo...@microsoft.com wrote:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1
currently says:
Audience A URI that
Hi Torsten,
Responses inline in blue.
On 12/25/2012 08:11 AM, Torsten Lodderstedt wrote:
Hi Amanda,
thank you for reviewing the draft. Comments inline.
Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
Here is my review of the Toke Revocation draft
I agree that “URI” should be changed to “value” for audience in the
Assertions Spec (draft-ietf-oauth-assertions) as well as the JWT
incarnation of it (draft-ietf-oauth-jwt-bearer). The SAML incarnation
(draft-ietf-oauth-saml2-bearer) should probably keep URI because that's how
the core SAML
Depending on the authorization server's revocation policy, the
revocation of a particular token may cause the revocation of related
tokens and the underlying authorization.
If the particular token is a refresh token and the authorization server
supports the revocation of access tokens, then
Am 27.12.2012 12:44, schrieb Sergey Beryozkin:
Hi again,
On 27/12/12 09:41, Sergey Beryozkin wrote:
Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec,
Am 27.12.2012 10:57, schrieb Sergey Beryozkin:
sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:
Hi all,
any other opinion regarding having or not having a token type parameter?
I would like to go with #1 as it is rather late in the process to
(re-)introduce a mandatory parameter. And making
Hi Amanda,
I incoporated your comments. I'm waiting for feedback on the other
threads before I will post another revision.
http://www.ietf.org/mail-archive/web/oauth/current/msg10334.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10331.html
Folks,
The OAuth 2.0 Resource Set Registration draft is essentially a generic first
phase of the User Managed Access (UMA) profile of OAuth2.0. This allows the RO
to register (make known) to the AS the resources he/she wishes to share.
Looking forward to comments/feedback.
/thomas/
Hi Thomas,
Here is some initial feedback.
Introduction paragraph 2:
Remove duplicate with: the OpenID Provider (OP) component is a
specialized version of an OAuth authorization server that brokers
availability of user attributes by dealing *with with* an ecosystem of
attribute providers (APs).
Concern here is that value could be an “interpretation” and thus you may get
different results that you don’t get when it’s a URI
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Wednesday, December 26, 2012 10:46 PM
To: Mike Jones
Cc:
What do you mean by multi-valued and what are the semantics of multi-vale ?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Bradley
Sent: Thursday, December 27, 2012 5:32 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Must the Audience value in the
Thanks Amanda,
- Scope and types: We went back and forth with regards to scope type and
finally just used type with the assumption that the reader would know what we
mean by it (ie. context dependent). However, we're very open to going back to
the previous language.
- Resource set
The discussion on the Connect call was that audience could be a literal or an
array.
example
aud:[http://audiance1.com,http://audiance2.com;]
In some cases the token may want to have more than a single audience.
(anthropomorphic license)
in the simple case it would still be
Amanda, thanks for the lightning-fast comments back. A couple of additional
notes on top of Thomas's response:
The scope type language is indeed new this time -- of course this whole
modular spec is newly broken out, but the previous text from UMA's rev 05 still
said scope. (There's a new
19 matches
Mail list logo
