Subject: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 10 Dec 2012 10:33:57 -0800

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'Assertion Framework for OAuth 2.0'
  <draft-ietf-oauth-assertions-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-12-24. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This specification provides a framework for the use of assertions
   with OAuth 2.0 in the form of a new client authentication mechanism
   and a new authorization grant type.  Mechanisms are specified for
   transporting assertions during interactions with a token endpoint, as
   well as general processing rules.

   The intent of this specification is to provide a common framework for
   OAuth 2.0 to interwork with other identity systems using assertions,
   and to provide alternative client authentication mechanisms.

   Note that this specification only defines abstract message flows and
   processing rules.  In order to be implementable, companion
   specifications are necessary to provide the corresponding concrete
   instantiations.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: [email-masked]
Date: Thu, 13 Dec 2012 15:04:37 +0800

In "section 3
 The token service is the assertion issuer; its
 role is to fulfill requests from clients, which present various
 credentials, and mint assertions as requested, fill them with
 appropriate information, and sign them."

As I understand, an assertion generated by a STS, is done flollowing thess 
steps:
1. Client presents credential and requests an assertion
2. STS generates assertion and sends to Client
Correct?

That may restrict the use cases that this assertion framework could 
support,
is it a must?

[email-masked] 写于 2012-12-11 02:33:57:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 13 Dec 2012 08:39:03 -0800

The language is simply meant to help illustrate how the framework might be used.   How do you think it will restrict usage?   How could it be improved?

-cmort

On Dec 12, 2012, at 11:04 PM, <[email-masked]<mailto:[email-masked]>> wrote:

In "section 3

As I understand, an assertion generated by a STS, is done flollowing thess steps:
1. Client presents credential and requests an assertion
2. STS generates assertion and sends to Client
Correct?

That may restrict the use cases that this assertion framework could support,
is it a must?

[email-masked]<mailto:[email-masked]> 写于 2012-12-11 02:33:57:

> [email-masked]<mailto:[email-masked]> mailing lists by 2012-12-24. Exceptionally, comments may be
> sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Fri, 14 Dec 2012 08:29:47 +0800

From the language, I got an impression that assertion is only generated by 
token service after clients presenting some credentials,
there are may be some cases that "assertion" don't need client's 
credential.
e.g., Resource owner as a token service  could generate "assertion" to a 
client he trusts, bu signing a statement that "This delegation is given to 
a client called clinet-id 
for doing something for me".

Chuck Mortimore <[email-masked]> 写于 2012-12-14 00:39:03:

> The language is simply meant to help illustrate how the framework 
> might be used.   How do you think it will restrict usage?   How 
> could it be improved?
> 
> -cmort
> 
> On Dec 12, 2012, at 11:04 PM, <[email-masked]> wrote:
> 
> 
> In "section 3 
support,

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 13 Dec 2012 18:08:34 -0800

On Dec 13, 2012, at 4:30 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

From the language, I got an impression that assertion is only generated by token service after clients presenting some credentials,
there are may be some cases that "assertion" don't need client's credential.
e.g., Resource owner as a token service  could generate "assertion" to a client he trusts, bu signing a statement that "This delegation is given to a client called clinet-id
for doing something for me".

So how does the STS trust the client?   Presumably if it is trusted it has some level of authentication, yes?

-cmort

---

From: [email-masked]
Date: Fri, 14 Dec 2012 10:26:50 +0800

I am not sure if the following usecase 
http://www.ietf.org/mail-archive/web/oauth/current/msg10233.html
could be supported by assertion framework，
We have some discussion in 
http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10198.html 

In my use case or in some other cases, assertions don't need confidential 
protection, 
basically STS don't have to authenticate a client before issueing 
"assertion", if it could be called assertion here.

Example,I trust my laywer, I may issue an "assertion" stating delegation 
in advance, and send to the lawyer when it is needed,
it could be I give the assertion to a false lawyer, but it does not 
matter, because the lawyer has to prove he knows some credential 
corresponding to his ID,
who is delegated some rights.

If assertion framework want to support this use case, then generation of 
assertion should be relaxed,
otherwise new work is required to support the use case.

Chuck Mortimore <[email-masked]> 写于 2012-12-14 10:08:34:

> On Dec 13, 2012, at 4:30 PM, "[email-masked]" 
<[email-masked]
> > wrote:

> 
> From the language, I got an impression that assertion is only 
> generated by token service after clients presenting some credentials, 
credential. 
> e.g., Resource owner as a token service  could generate "assertion" 
> to a client he trusts, bu signing a statement that "This delegation 
> is given to a client called clinet-id 
> So how does the STS trust the client?   Presumably if it is trusted 
> it has some level of authentication, yes?
> 
> -cmort
> 
> 
> 
> 
>

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 13 Dec 2012 18:34:13 -0800

You want a holder of key pattern.  The draft touches on it

   The protocol parameters and processing rules defined in this document
   are intended to support a client presenting a bearer assertion to an
   authorization server.  The use of holder-of-key assertions are not
   precluded by this document, but additional protocol details would
   need to be specified.

So - if you want this, you should put forth a holder of key profiling of this draft and see if there are any issues.   The only profiles we have thus far are saml and jwt bearer assertions.

- cmort

On Dec 13, 2012, at 6:27 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

I am not sure if the following usecase  http://www.ietf.org/mail-archive/web/oauth/current/msg10233.html

In my use case or in some other cases, assertions don't need confidential protection,
basically STS don't have to authenticate a client before issueing "assertion", if it could be called assertion here.

Example,I trust my laywer, I may issue an "assertion" stating delegation in advance, and send to the lawyer when it is needed,
it could be I give the assertion to a false lawyer, but it does not matter, because the lawyer has to prove he knows some credential corresponding to his ID,
who is delegated some rights.

If assertion framework want to support this use case, then generation of assertion should be relaxed,
otherwise new work is required to support the use case.

Chuck Mortimore <[email-masked]<mailto:[email-masked]>> 写于 2012-12-14 10:08:34:

> On Dec 13, 2012, at 4:30 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
> > wrote:

---

From: [email-masked]
Date: Fri, 14 Dec 2012 10:39:19 +0800

Oh, But the description of assertion generation in the document should not 
be limited by bear assertion, right?

> 
> So - if you want this, you should put forth a holder of key 
> profiling of this draft and see if there are any issues.   The only 
> profiles we have thus far are saml and jwt bearer assertions. 
> 
> 
> - cmort
> 
> On Dec 13, 2012, at 6:27 PM, "[email-masked]" 
<[email-masked]

> Example,I trust my laywer, I may issue an "assertion" stating 
> delegation in advance, and send to the lawyer when it is needed, 
> If assertion framework want to support this use case, then 
> generation of assertion should be relaxed, 
> > On Dec 13, 2012, at 4:30 PM, "[email-masked]" <zhou.
> [email-masked]
> > > wrote:
> 
> >

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 13 Dec 2012 18:44:05 -0800

Correct.   That said no one has yet profiled it for holder of key

- cmort

On Dec 13, 2012, at 6:39 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Oh, But the description of assertion generation in the document should not be limited by bear assertion, right?

> On Dec 13, 2012, at 6:27 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
> > wrote:

> > On Dec 13, 2012, at 4:30 PM, "[email-masked]<mailto:[email-masked]>" <zhou.
> [email-masked]<mailto:[email-masked]>
> > > wrote:
>
> >

---

From: [email-masked]
Date: Fri, 14 Dec 2012 10:55:57 +0800

Yep, could do it soon later. 

Currently, I suggest a modification for 

 "The token service is the assertion issuer; its  role is to fulfill 
requests from clients, which present various 
 credentials, and mint assertions as requested, fill them with appropriate 
information, and sign them."  (in  section 3 )

into 

 "The token service is the assertion issuer, it could be implemented in 
any entity besides client, e.g., Resource Owner, Authorization Server; its 
 role is to fulfill requests from clients, which present various 
credentials, and mint assertions as requested, fill them with  appropriate 
information, and sign them." 

Chuck Mortimore <[email-masked]> 写于 2012-12-14 10:44:05:

> On Dec 13, 2012, at 6:39 PM, "[email-masked]" 
<[email-masked]

> 
> Oh, But the description of assertion generation in the document 
> should not be limited by bear assertion, right? 
> 
> 
> > On Dec 13, 2012, at 6:27 PM, "[email-masked]" <zhou.
> [email-masked]
> > > wrote:
> 
> > 
> > > > As I understand, an assertion generated by a STS, is done 
flollowing
> > > > thess steps: 
> > > > >    with OAuth 2.0 in the form of a new client 
authenticationmechanism

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 15 Dec 2012 00:02:58 +0900

FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim
'cid'.

=nat via iPhone

Dec 14, 2012 11:56、"[email-masked]" <[email-masked]> のメッセージ:

into

 "The token service is the assertion issuer, *it could be implemented in
any entity besides client, e.g., Resource Owner, Authorization Server;* its
 role is to fulfill requests from clients, which present various
 credentials, and mint assertions as requested, fill them with  appropriate
information, and sign them."

Chuck Mortimore <[email-masked]> 写于 2012-12-14 10:44:05:

> On Dec 13, 2012, at 6:39 PM, "[email-masked]" <
[email-masked]

authenticationmechanism