James,
On Mon, May 31, 2010 at 10:17 AM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> Nat,
>
> > All the request parameters MUST be provided through request file.
>
> "All" doesn't make much sense if params can still appear in the URI, and
> override the file.
>
What about this:
I probably exaggerated a bit. It's not impossible but it is complex and
insecure for several reasons:
1) Such a super token would need to contain the union of all data and
permissions needed by all requested target services.
2) Not all services may by authorized to see all data contained in suc
+1 for solution 2
Regarding usage of the scope attribute: As Dick suggested, the spec
should state that the client should pass the scope attributes content to
the corresponding scope parameter in any authorization flow. Moreover, I
would suggest, clients should be allowed to combine scopes fro
Hi!
I'm curious why this is impossible. If access tokens are arbitrary
handles which are generated by the authorization server and
distributed to all resources, it doesn't make much difference whether
one or multiple are generated and in this case it would be better to
keep the load on the server r
On 2010-06-03, at 8:20 AM, Peter Saint-Andre wrote:
> On 6/3/10 8:54 AM, Thomas Hardjono wrote:
>
>> PS. Compared to the details of RFC4120 and even
>> to the old ISAKMP in the IETF, the current
>> OAuth2.0 draft-05 spec appear to be a high-level framework
>> that needs to be instantiated/profil
On 2010-06-03, at 7:54 AM, Thomas Hardjono wrote:
> Dick, Brian,
>
> Thanks for the clarification.
>
> - Is the Assertion Flow designed only for the STS,
> or can it be used with other "identity providers" (non-WSS).
It can be used with any tokens. I use the STS term to clarify the design
pat
I think STS was used in the generic sense, ie token in, token out
Although a SOAP-binding for the flow would be wonderfully perverse
paul
On 03/06/2010 10:54 AM, Thomas Hardjono wrote:
Dick, Brian,
Thanks for the clarification.
- Is the Assertion Flow designed only for the STS,
or can it be
On 6/3/10 8:54 AM, Thomas Hardjono wrote:
> PS. Compared to the details of RFC4120 and even
> to the old ISAKMP in the IETF, the current
> OAuth2.0 draft-05 spec appear to be a high-level framework
> that needs to be instantiated/profiled.
At least for the assertion flow, that's definitely true.
Dick, Brian,
Thanks for the clarification.
- Is the Assertion Flow designed only for the STS,
or can it be used with other "identity providers" (non-WSS).
- Also, is it the expectation that a "profile" of OAuth2.0
be created to address certain use-cases.
PS. Compared to the details of RFC4120 a
If I understand you correct, then you could utilize the assertion flow
as follows:
Put the generic token into the assertion parameter, set the scopes
parameter to the scope(s) of the service your client wants to interact
with and use the client credentials as described. If the AS supports
suc
10 matches
Mail list logo
