As long as:
- You can provide a URI identifier for the assertion format you are going to
use, and
- The authorization server can do something useful with the assertion provided
and decide if it should grant an access token
Then sure, you can use the assertion flow for utilizing any other trust
off again.
>
> /thomas/
>
> __
>
>
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Sunday, June 06, 2010 8:10 PM
>> To: Thomas Hardjono
>> Cc: oauth@ietf.org
>> Subject:
Hardt [mailto:dick.ha...@gmail.com]
> Sent: Sunday, June 06, 2010 8:10 PM
> To: Thomas Hardjono
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping
>
> I hope so.
>
> On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote:
>
> > Apologies for
;
> /thomas/
>
> __
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
>> Dick Hardt
>> Sent: Friday, June 04, 2010 9:59 PM
>> To: Luke Shepard
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUT
tf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Dick Hardt
> Sent: Friday, June 04, 2010 9:59 PM
> To: Luke Shepard
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping
>
> because we use it
>
> On 2010-06-04, at 6:40 PM, Luke Shepard wr
because we use it
On 2010-06-04, at 6:40 PM, Luke Shepard wrote:
> Why?
>
> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote:
>
>> +1
>>
>> Sent from my iPhone
>>
>> On Jun 4, 2010, at 5:38 PM, Brian Campbell
>> wrote:
>>
>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
>>> wrote
Why?
On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote:
> +1
>
> Sent from my iPhone
>
> On Jun 4, 2010, at 5:38 PM, Brian Campbell
> wrote:
>
>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
>> wrote:
>>>
>>> At least for the assertion flow, that's definitely true. At the
>>> int
+1
Sent from my iPhone
On Jun 4, 2010, at 5:38 PM, Brian Campbell
wrote:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
wrote:
At least for the assertion flow, that's definitely true. At the
interim
meeting we had some discussion about perhaps pulling the assertion
flow
out of
+1
Am 04.06.2010 23:38, schrieb Brian Campbell:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote:
At least for the assertion flow, that's definitely true. At the interim
meeting we had some discussion about perhaps pulling the assertion flow
out of the base spec and into a separate
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote:
>
> At least for the assertion flow, that's definitely true. At the interim
> meeting we had some discussion about perhaps pulling the assertion flow
> out of the base spec and into a separate document. Perhaps that's the
> best way to proce
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
high-level framework
that needs to be instantiated/profiled.
/thomas/
__
-From: Dick Hardt [mailto:dick.ha...@gmail.com]
-Sent: Thursday, June 03, 2010 1:51 AM
To: Brian Campbell
Cc: Thomas Hardjono; oauth
Subject: Re: [OAUTH-WG] Assertion flow and toke
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.
03, 2010 1:51 AM
To: Brian Campbell
Cc: Thomas Hardjono; oauth
Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping
The Assertion Flow is for the AS to act as an STS where one token is exchanged
for another. This allows the PR to not have to worry about different kinds of
tokens and to o
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
The Assertion Flow is for the AS to act as an STS where one token is
exchanged for another. This allows the PR to not have to worry about
different kinds of tokens and to only deal with tokens issued by an AS.
Lisa: a real world example of your use case would make it easier for how you
got to the
I'm still a newbie here so someone please correct me if I'm wrong, but
I believe the Assertion Flow was intentionally left generic to serve
as an extension point for profiling more specific types of
assertions/tokens being exchanged for OAuth Access Tokens (or allowing
for proprietary usage). The
Lisa,
I'm also looking at the assertion flow right now
and wondering if I could use it to "swap" a
Kerberos service-ticket for an OAuth Access-Token.
In particular, I would like to:
(1) Wrap the KRB AP_REQ message within a SAML-assertion
(eg. using the existing WSS Token Profile standard),
(2
19 matches
Mail list logo
