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 m
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
"aud":"http
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 regist
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 Ass
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: oauth@iet
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)
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 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
http://www.ietf.org/mail-archive/web/oaut
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
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, wh
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 the
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 speci
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
(http://datatracker.ietf.org/doc/draft-ietf-o
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 wrote:
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1
> currently says:
>
>Audience A URI that identifies the party int
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
implementations
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 us
+1
Am 27.12.2012 um 02:43 schrieb Mike Jones :
> 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 Token Endpoint
> as
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 go
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 :
> Hi all,
>
> I had just submitted an u
19 matches
Mail list logo
