I am not objecting that RS should define it's requirements... and RS
should be able to do it by each resource... So ideally RS may have away to
express that in a WADL and we need to have a standard mechanism established
for communication between RS and AS.
In WS-Trust - SP can declare it's token
Prabath Siriwardena 写于 2013-01-21 15:27:57:
> I guess that is a pattern used many scenarios. Requesting client can
> suggest - but its up to the AS to honor it or not...
Not exactly. For example, RS supports two token types, one is bear token,
another is holer-of-key which is assumed more secur
I guess that is a pattern used many scenarios. Requesting client can
suggest - but its up to the AS to honor it or not...
Thanks & regards,
-prabath
On Mon, Jan 21, 2013 at 12:43 PM, wrote:
>
> William Mills 写于 2013-01-21 13:44:45:
>
>
> > Not a problem for the client to request a type, but it
William Mills 写于 2013-01-21 13:44:45:
> Not a problem for the client to request a type, but it may not get it.
I don't object client requesting a type, but I think it is meaningful only
when the requested type is specified by a RS,
and client just relay that request to AS.
>
> From: "zhou.suj.
Not a problem for the client to request a type, but it may not get it.
From: "zhou.suj...@zte.com.cn"
To: Prabath Siriwardena
Cc: "oauth@ietf.org WG" ; William Mills
Sent: Sunday, January 20, 2013 9:38 PM
Subject: Re: Re: Re: [OAUTH-WG] Client cannot specif
Well, if RS could specify token type, then Client could transfer it to AS,
I think, but it is not a good idea for client itself to specify the token
type.
Prabath Siriwardena 写于 2013-01-21 13:29:05:
> Think about a distributed setup. You have single Authorization
> Server and multiple Reso
Think about a distributed setup. You have single Authorization Server and
multiple Resource Servers.
Although OAuth nicely decouples AS from RS - AFAIK there is no standard
established for communication betweens AS and RS - how to declare metadata
between those.
Also there can be Resource Servers
The token type shoulbe decided by resource server, which consumes access
token.
Client just re-tell the requested token type to AS.
Client should not specify the token type.
oauth-boun...@ietf.org 写于 2013-01-21 13:08:39:
> This is true. It's possible for the AS to vary it's behavior on
> sco
This is true. It's possible for the AS to vary it's behavior on scope name,
but it's presumed the AS and RS have an agreement of what token type is in
play. Likely a good extension to the spec.
From: Prabath Siriwardena
To: "oauth@ietf.org WG"
Sent: Sunday
Although token type is extensible according to the OAuth core specification
- it is fully governed by the Authorization Server.
There can be a case where a single AS supports multiple token types based
on client request.
But currently we don't have a way the client can specify (or at least
sugges
Hi,
On 03/01/13 22:45, Justin Richer wrote:
I'd like to present two use cases for signed tokens, for input into the
ongoing MAC/HoK/higher-security discussion. Both of these are actual
cases that I've done in the past, and we've used either OAuth 1 or JW*
to solve them. I think that with the righ
11 matches
Mail list logo
