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. At
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 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
pattern.
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/profiled.
At
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
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
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:
Request
