Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

From: Nat Sakimura <[email-masked]>
Date: Mon, 3 Dec 2012 17:35:05 +0900

Hi Brian,

The assertion framework defines the Issuer as:

   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.

I was wondering why it has to be either the client or a third party
token service.

Conceptually, it could be any token service (functionality) residing in any of

the stakeholders (Resource Owner, OAuth Client, Authorization Server, or

a third party).

I would appreciate if you could clarify why is the case.

Best,

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 3 Dec 2012 10:49:11 +0200

Hi Nat, 

The current text essentially says that the assertion can either be
created by the client (in which case it is self-signed) or it can be
created by some other entity (which is then called the third party token
service). So, this third party could be the authorization server. 

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Nat Sakimura
Sent: Monday, December 03, 2012 10:35 AM
To: Brian Campbell; oauth
Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be
either the client or a third party token service?

Hi Brian, 

 
I was wondering why it has to be either the client or a third party
token service. 
Conceptually, it could be any token service (functionality) residing in
any of 

a third party). 

Best, 

-- 
Nat Sakimura (=nat)

---

From: [email-masked]
Date: Mon, 3 Dec 2012 16:52:35 +0800

could be Resource owner? 

"Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> 
发件人:  [email-masked]
2012-12-03 16:49

收件人
"ext Nat Sakimura" <[email-masked]>, "Brian Campbell" 
<[email-masked]>, "oauth" <[email-masked]>
抄送

主题
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the 
client or a third party token service?

Hi Nat, 
 
The current text essentially says that the assertion can either be created 
by the client (in which case it is self-signed) or it can be created by 
some other entity (which is then called the third party token service). 
So, this third party could be the authorization server. 
 
Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
ext Nat Sakimura
 
Hi Brian, 

 
I was wondering why it has to be either the client or a third party token 
service. 
Conceptually, it could be any token service (functionality) residing in 
any of 

Best, 
 
-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 _______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 3 Dec 2012 00:58:27 -0800

I suppose, yes. I was reading it like that all the time.
Whether it is or not, if it is still ok, it might be better to clarify it.
Word like "third party" tends to be a bit of problem without clearly
defining.
I had similar experience in other fora.

Nat

Sent from iPad

2012/12/03 0:52、"[email-masked]" <[email-masked]> のメッセージ:

could be Resource owner?

 *"Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>*
发件人:  [email-masked]

2012-12-03 16:49
  收件人
"ext Nat Sakimura" <[email-masked]>, "Brian Campbell" <
[email-masked]>, "oauth" <[email-masked]>
抄送
  主题
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
 either the client or a third party token service?

Hi Nat,

The current text essentially says that the assertion can either be created
by the client (in which case it is self-signed) or it can be created by
some other entity (which is then called the third party token service). So,
this third party could be the authorization server.

Ciao
Hannes

*From:* [email-masked]
[mailto:[email-masked]<[email-masked]>]
*On Behalf Of *ext Nat Sakimura*
Sent:* Monday, December 03, 2012 10:35 AM*
To:* Brian Campbell; oauth*
Subject:* [OAUTH-WG] Assertion Framework - Why does issuer have to be
either the client or a third party token service?

Hi Brian,

I was wondering why it has to be either the client or a third party token
service.
Conceptually, it could be any token service (functionality) residing in any
of

Best,

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation*
**http://nat.sakimura.org/* <http://nat.sakimura.org/>
@_nat_en
 _______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 03 Dec 2012 12:30:55 -0500

Actually, I think it is a good time to start looking at the resourse
owner issuing assertions@ (Interestingly enough, Hui-Lan had brought
this up a couple of years ago.)

Igor

On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> 2012/12/03 0:52、"[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> のメッセージ:
>
>>
>> could be Resource owner?
>>
>>
>> *"Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]
>> <mailto:[email-masked]>>*
>> 发件人: [email-masked] <mailto:[email-masked]>
>>
>> 2012-12-03 16:49
>>
>> 	
>> 收件人
>> 	"ext Nat Sakimura" <[email-masked] <mailto:[email-masked]>>,
>> "Brian Campbell" <[email-masked]
>> <mailto:[email-masked]>>, "oauth" <[email-masked]
>> <mailto:[email-masked]>>
>> 抄送
>> 	
>> 主题
>> created by some other entity (which is then called the third party
>> token service). So, this third party could be the authorization server.
>>
>> Ciao
>> Hannes
>>
>>
>> *From:* [email-masked] <mailto:[email-masked]>
>> [mailto:[email-masked]] *On Behalf Of *ext Nat Sakimura*
>> Chairman, OpenID Foundation_
>> __http://nat.sakimura.org/_
>> @_nat_en
>> [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Tue, 4 Dec 2012 10:06:50 +0800

+1.
And why it was not looked at that time? 

[email-masked] 写于 2012-12-04 01:30:55:

> Word like "third party" tends to be a bit of problem without 
clearlydefining. 

> 发件人:  [email-masked] 
Of 

> Conceptually, it could be any token service (functionality) residingin 
any of

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 3 Dec 2012 18:12:52 -0800

It's simply the entity that created the assertion.   Third party token service was meant to encapsulate pretty much all of your stakeholders below.   The only one it doesn't really cover is Authorization Server.

On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote:

Hi Brian,

I was wondering why it has to be either the client or a third party token service.

a third party).

Best,

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

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 3 Dec 2012 18:15:48 -0800

Actually - strike that.   Authorization server is covered by the language as well.

In short, Issuer is simply the entity that minted the assertion.   The intent is to allow the token service to lookup metadata about the issuer used to establish trust ( their Public Key for instance )

On Dec 3, 2012, at 6:12 PM, Chuck Mortimore wrote:

Hi Brian,

a third party).

Best,

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 3 Dec 2012 18:17:12 -0800

There's no reason why it can't be resource owner today.

On Dec 3, 2012, at 6:06 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

+1.

[email-masked]<mailto:[email-masked]> 写于 2012-12-04 01:30:55:

> Word like "third party" tends to be a bit of problem without clearlydefining.
> 2012/12/03 0:52、"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> の
> メッセージ:

>
> "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]<mailto:[email-masked]>>
> 发件人:  [email-masked]<mailto:[email-masked]>
> 2012-12-03 16:49
>
> 收件人
>
> "ext Nat Sakimura" <[email-masked]<mailto:[email-masked]>>, "Brian Campbell" <
> [email-masked]<mailto:[email-masked]>>, "oauth" <[email-masked]<mailto:[email-masked]>>
>
> 抄送
>
> 主题
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
> ext Nat Sakimura
> Conceptually, it could be any token service (functionality) residingin any of
>

---

From: [email-masked]
Date: Tue, 4 Dec 2012 10:23:22 +0800

Obviously, it is not so clear from the language there.

Chuck Mortimore <[email-masked]> 写于 2012-12-04 10:17:12:

> On Dec 3, 2012, at 6:06 PM, <[email-masked]> 
<[email-masked]
> > wrote:
Of

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 3 Dec 2012 18:26:50 -0800

Please feel free to suggest better language.

Issuer simply allows the token service to know who created the assertion, so it can look them up and see if they're trusted.     Effectively the same as an Issuer in SAML.

-cmort

On Dec 3, 2012, at 6:23 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Chuck Mortimore <[email-masked]<mailto:[email-masked]>> 写于 2012-12-04 10:17:12:

> On Dec 3, 2012, at 6:06 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>
> > wrote:
>
>
> +1.

---

From: [email-masked]
Date: Tue, 4 Dec 2012 10:40:09 +0800

Chuck Mortimore <[email-masked]> 写于 2012-12-04 10:26:50:

> Issuer simply allows the token service to know who created the 
> assertion, so it can look them up and see if they're trusted. 
> Effectively the same as an Issuer in SAML.

a conflict : "The token service is the assertion issuer" in assertion 
document.
while you said "token service know who created the assertion"

I wonder if the following text is acceptable:
 
  Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or any other 
entity, e.g.,  a third party 
token service, resource owner.

6.3.  Client Acting on Behalf of a User

The Issuer of the assertion MUST identify the entity that issued
      the assertion as recognized by the Authorization Server.  If the
      assertion is self-issued, the Issuer SHOULD be the "client_id".
      If the assertion was issued by a Security Token Service (STS), the
      Issuer SHOULD identify the STS as recognized by the Authorization
      Server.If the assertion was issued by the resource owner, the
      Issuer SHOULD identify the resource owner as recognized by the 
Authorization
      Server.

> 
> -cmort
> 
> On Dec 3, 2012, at 6:23 PM, <[email-masked]> wrote:
> 
> 
<[email-masked]
> > > 2012/12/03 0:52、"[email-masked]" <[email-masked]> 
の

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Dec 2012 13:20:39 +0900

Actually, "The issuer may be either
      an OAuth client (when assertions are self-issued) or any other
entity, e.g.,  a third party
token service, resource owner. "  is not really clean.

OAuth client is just another example of an issuer.

So, perhaps the sentence could be:

"Example of issuers include an OAuth client, resource owner, an independent
third party."

So, the clause becomes:

 Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.
      Example of issuers include an OAuth client, resource owner, an
independent third party.

Nat

Nat

On Tue, Dec 4, 2012 at 11:40 AM, <[email-masked]> wrote:

> > > On Dec 3, 2012, at 6:06 PM, <[email-masked]> <
> [email-masked]
> > > > wrote:
> > >
> > >
> > > +1.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 4 Dec 2012 08:41:08 -0700

The intent was definitely not to constrain who/what could be the issuer.
But also try to provide
some guidance around the common cases that are actually being deployed now,
which are the client self-issued and STS variants. Resource owner as an
issuer is an interesting case but seems mostly theoretical at this point.

I feel like mentioning the resource owner there in §5.1 would cause more
confusion than anything else. I'd prefer to just strike the whole sentence
in question and maybe add some additional text to §3 that clarifies that
the issuer can really be any entity, if folks think a change is needed
here?

On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <[email-masked]> wrote:

> "Example of issuers include an OAuth client, resource owner, an
> independent third party."
>
> So, the clause becomes:
>

---

From: [email-masked]
Date: Wed, 5 Dec 2012 08:39:11 +0800

Why RO as an issuer is only theoretical today?

Brian Campbell <[email-masked]> 
2012-12-04 23:41

收件人
Nat Sakimura <[email-masked]>
抄送
[email-masked], "[email-masked]" <[email-masked]>
主题
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the 
client or a third party token service?

The intent was definitely not to constrain who/what could be the issuer. 
But also try to provide 
some guidance around the common cases that are actually being deployed 
now, which are the client self-issued and STS variants. Resource owner as 
an issuer is an interesting case but seems mostly theoretical at this 
point.

So, the clause becomes: 

Nat

Nat

  

[email-masked]
の

---

From: Brian Campbell <[email-masked]>
Date: Wed, 5 Dec 2012 07:05:25 -0700

I say that it's only theoretical because I don't believe there are any
actual deployments supporting, or planning on supporting, RO as an
assertion issuer.

On Tue, Dec 4, 2012 at 5:39 PM, <[email-masked]> wrote:

>  *Brian Campbell <[email-masked]>*
>
> 2012-12-04 23:41
>   收件人
> an issuer is an interesting case but seems mostly theoretical at this point.
>
> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <[email-masked]*<[email-masked]>>
> wrote:
> On Tue, Dec 4, 2012 at 11:40 AM, <[email-masked]*<[email-masked]>>
> wrote:
>
>
>
> Chuck Mortimore <[email-masked]* <[email-masked]>>
> 写于 2012-12-04 10:26:50:
>
>
> > On Dec 3, 2012, at 6:23 PM, <[email-masked]*<[email-masked]>>
> wrote:
> >
> >
> > Chuck Mortimore <[email-masked]* <[email-masked]>>
> 写于 2012-12-04 10:17:12:
> >
> > > On Dec 3, 2012, at 6:06 PM, <[email-masked]*<[email-masked]>>
> <[email-masked]* <[email-masked]>
> > > > wrote:
> > >
> > >
> > > +1.
> > > [email-masked]* <[email-masked]> 写于 2012-12-04
> 01:30:55:
> > >
> > > > 2012/12/03 0:52、"[email-masked]* <[email-masked]>"
> <[email-masked]* <[email-masked]>> の
> > > > メッセージ:
> > >
> > > >
> > > > could be Resource owner?
> > > >
> > >
> > > >
> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]*<[email-masked]>>
>
> > > > 发件人:  [email-masked]* <[email-masked]>
> > > > 2012-12-03 16:49
> > > >
> > > > 收件人
> > > >
> > > > "ext Nat Sakimura" <[email-masked]* <[email-masked]>>,
> "Brian Campbell" <
> > > > [email-masked]* <[email-masked]>>, "oauth"
> <[email-masked]* <[email-masked]>>
> > > >
> > > > 抄送
> > > >
> > > > 主题
> > > >
> > > > From: [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] On Behalf Of
> > > > ext Nat Sakimura
> > > > *http://nat.sakimura.org/* <http://nat.sakimura.org/>
> > > > @_nat_en
> > > > [email-masked]* <[email-masked]>
> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
> > >
> > > >
> > > >
> > > > [email-masked]* <[email-masked]>
> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
> > > > [email-masked]* <[email-masked]>
> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
> > > [email-masked]* <[email-masked]>
> > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
> OAuth mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> --
> Nat Sakimura (=nat)
> OAuth mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 5 Dec 2012 14:48:49 +0000

Hi Brian,

This is sort of my feeling on the STS as well (theoretical).  Are there any real-life examples of obtaining a JWT assertion from an STS that can be used for the assertion flow?  And if so then how is it obtained?  It cannot be an id_token because that is audience restricted to the client.  I guess it could be an access_token with a scope of assertion?  But I’ve not seen any discussion of that.  I’ve been interested in this flow for a while but the only examples I’m aware of are self-issued JWTs.  I’d be very interested in knowing real life of examples of clients obtaining a JWT assertion from an STS to use as a grant, and the method they use to do that.

tx
adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, December 05, 2012 8:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

I say that it's only theoretical because I don't believe there are any actual deployments supporting, or planning on supporting, RO as an assertion issuer.

On Tue, Dec 4, 2012 at 5:39 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Brian Campbell <[email-masked]<mailto:[email-masked]>>

2012-12-04 23:41

收件人

Nat Sakimura <[email-masked]<mailto:[email-masked]>>

抄送

[email-masked]<mailto:[email-masked]>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

The intent was definitely not to constrain who/what could be the issuer.  But also try to provide
some guidance around the common cases that are actually being deployed now, which are the client self-issued and STS variants. Resource owner as an issuer is an interesting case but seems mostly theoretical at this point.

I feel like mentioning the resource owner there in §5.1 would cause more confusion than anything else. I'd prefer to just strike the whole sentence in question and maybe add some additional text to §3 that clarifies that the issuer can really be any entity, if folks think a change is needed here?

On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
Actually, "The issuer may be either
      an OAuth client (when assertions are self-issued) or any other entity, e.g.,  a third party
token service, resource owner. "  is not really clean.

"Example of issuers include an OAuth client, resource owner, an independent third party."

So, the clause becomes:

 Issuer  The unique identifier for the entity that issued the
     assertion.  Generally this is the entity that holds the key
     material used to generate the assertion.
      Example of issuers include an OAuth client, resource owner, an independent third party.

Nat

Nat

On Tue, Dec 4, 2012 at 11:40 AM, <[email-masked]<mailto:[email-masked]>> wrote:

> Effectively the same as an Issuer in SAML.

a conflict : "The token service is the assertion issuer" in assertion document.
while you said "token service know who created the assertion"

      an OAuth client (when assertions are self-issued) or any other entity, e.g.,  a third party

     Issuer SHOULD identify the resource owner as recognized by the Authorization
     Server.

> > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > > ext Nat Sakimura

---

From: Brian Campbell <[email-masked]>
Date: Wed, 5 Dec 2012 08:37:43 -0700

Hi Adam,

My employer's product supports the STS case for getting SAML to be used in
the assertion flow. We and the employer of one of my co-authors on the spec
have a few very significant mutual customers that are using it today. The
JWT variant is 'on the road map' as we juggle other priorities and wait for
JOSE/JWT specs to stabilize a little more. It's just a different token
format from SAML though so I view it as much more concrete and likely to
happen. Granted the nature of JWT lends itself better to the self-signed
case so I think that will be more common but certainly won't preclude the
STS case.

On Wed, Dec 5, 2012 at 7:48 AM, Lewis Adam-CAL022 <
[email-masked]> wrote:

>  Hi Brian,****
>
> ** **
>
> This is sort of my feeling on the STS as well (theoretical).  Are there
> any real-life examples of obtaining a JWT assertion from an STS that can be
> used for the assertion flow?  And if so then how is it obtained?  It cannot
> be an id_token because that is audience restricted to the client.  I guess
> it could be an access_token with a scope of assertion?  But I’ve not seen
> any discussion of that.  I’ve been interested in this flow for a while but
> the only examples I’m aware of are self-issued JWTs.  I’d be very
> interested in knowing real life of examples of clients obtaining a JWT
> assertion from an STS to use as a grant, and the method they use to do that.
> ****
>
> ** **
>
> tx****
>
> adam****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Campbell
> *Sent:* Wednesday, December 05, 2012 8:05 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Assertion Framework - Why does issuer have to
> be either the client or a third party token service?****
>
> ** **
>
> assertion issuer. ****
> ** **
> On Tue, Dec 4, 2012 at 5:39 PM, <[email-masked]> wrote:****
>
>
> ****
> *Brian Campbell <[email-masked]>* ****
>
> 2012-12-04 23:41 ****
>
> 收件人****
>
> Nat Sakimura <[email-masked]> ****
>
> 抄送****
>
> [email-masked], "[email-masked]" <[email-masked]> ****
>
> 主题****
>
> client or a third party token service?****
>
> ** **
>
>
>
>
> [email-masked]*
> *https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=nat)
> *http://nat.sakimura.org/
> @_nat_en
>
>
> [email-masked]*
> *https://www.ietf.org/mailman/listinfo/oauth
>
> ****
>
> ** **
>

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 05 Dec 2012 11:41:06 -0500

We have a number of use-cases where a user's authentication/session is 
locally exchanged for a SAML assertion by a client; the client then uses 
the SAML assertion to acquire an OAuth 2.0 access token from a service 
provider and goes onto use services from the provider.

Its more of an instance of the "STS pattern" than an explicit use of a 
STS (or WS-Trust exchange) but it fits easily with the SAML 2.0 Bearer 
assertion profile for OAuth 2.0.
> Hi Adam,
>
> My employer's product supports the STS case for getting SAML to be 
> used in the assertion flow. We and the employer of one of my 
> co-authors on the spec have a few very significant mutual customers 
> that are using it today. The JWT variant is 'on the road map' as we 
> juggle other priorities and wait for JOSE/JWT specs to stabilize a 
> little more. It's just a different token format from SAML though so I 
> view it as much more concrete and likely to happen. Granted the nature 
> of JWT lends itself better to the self-signed case so I think that 
> will be more common but certainly won't preclude the STS case.
>
>
> On Wed, Dec 5, 2012 at 7:48 AM, Lewis Adam-CAL022 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Brian,
>
>     This is sort of my feeling on the STS as well (theoretical).  Are
>     there any real-life examples of obtaining a JWT assertion from an
>     STS that can be used for the assertion flow?  And if so then how
>     is it obtained?  It cannot be an id_token because that is audience
>     restricted to the client.  I guess it could be an access_token
>     with a scope of assertion? But I've not seen any discussion of
>     that.  I've been interested in this flow for a while but the only
>     examples I'm aware of are self-issued JWTs.  I'd be very
>     interested in knowing real life of examples of clients obtaining a
>     JWT assertion from an STS to use as a grant, and the method they
>     use to do that.
>
>     tx
>
>     adam
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *Brian Campbell
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [OAUTH-WG] Assertion Framework - Why does issuer
>     have to be either the client or a third party token service?
>
>     I say that it's only theoretical because I don't believe there are
>     any actual deployments supporting, or planning on supporting, RO
>     as an assertion issuer.
>
>     *Brian Campbell <[email-masked]
>     <mailto:[email-masked]>>*
>
>     2012-12-04 23:41
>
>     	
>
>     ???
>
>     	
>
>     Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>
>     ??
>
>     	
>
>     [email-masked] <mailto:[email-masked]>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>
>     ??
>
>     	
>
>     some guidance around the common cases that are actually being
>     deployed now, which are the client self-issued and STS variants.
>     Resource owner as an issuer is an interesting case but seems
>     mostly theoretical at this point.
>
>     I feel like mentioning the resource owner there in §5.1 would
>     cause more confusion than anything else. I'd prefer to just strike
>     the whole sentence in question and maybe add some additional text
>     to §3 that clarifies that the issuer can really be any entity, if
>     folks think a change is needed here?
>
>
>
>         an OAuth client (when assertions are self-issued) orany other
>     Chuck Mortimore <[email-masked]
>     <mailto:[email-masked]>> ?? 2012-12-04 10:26:50:
>
>
>           an OAuth client (when assertions are self-issued) orany
>     other entity, e.g., a third party
>     > Chuck Mortimore <[email-masked]
>     <mailto:[email-masked]>> ?? 2012-12-04 10:17:12:
>     >
>     > > On Dec 3, 2012, at 6:06 PM, <[email-masked]
>     <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>
>     > > > wrote:
>     > >
>     > >
>     > > +1.
>     > > [email-masked] <mailto:[email-masked]>??
>     2012-12-04 01:30:55:
>     > >
>     > > > 2012/12/03 0:52?"[email-masked]
>     <mailto:[email-masked]>> ?
>     > > > ?? ???:
>     > >
>     > > >
>     > > > could be Resource owner?
>     > > >
>     > >
>     > > >
>     > > > "Tschofenig, Hannes (NSN - FI/Espoo)"
>     <[email-masked] <mailto:[email-masked]>>
>     > > > ???: [email-masked] <mailto:[email-masked]>
>     > > > 2012-12-03 16:49
>     > > >
>     > > > ???
>     > > >
>     > > > "ext Nat Sakimura" <[email-masked]
>     <mailto:[email-masked]>>, "Brian Campbell" <
>     > > > [email-masked]
>     > > > ??
>     > > > ??
>     > > > From: [email-masked]
>     <mailto:[email-masked]>[mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of
>     > > > ext Nat Sakimura
>     OAuth mailing list_
>     [email-masked] <mailto:[email-masked]>_
>     _https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>     _http://nat.sakimura.org/
>     @_nat_en
>
>
>     OAuth mailing list_
>     [email-masked] <mailto:[email-masked]>_
>     _https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 6 Dec 2012 02:13:39 +0900

It is not OAuth, but Austrian eID system is an example of RO as an
assertion issuer pattern. They have their own SAML IdP on their PC (at
least a few years ago) and combined with the qualified certs in the user's
smart card and another file, creates a SAML assertion with sectoral
identifier and supply it to other systems.

Nat

On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell
<[email-masked]>wrote:

>> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either
>> the client or a third party token service?
>>
>>
>>
>>
>> > Chuck Mortimore <[email-masked]*<[email-masked]>>
>> 写于 2012-12-04 10:17:12:
>> >
>> > > > [email-masked]* <[email-masked]>>,
>> "oauth" <[email-masked]* <[email-masked]>>
>> > > >
>> > > > 抄送
>> > > >
>> > > > 主题
>> > > >

---

From: Eve Maler <[email-masked]>
Date: Wed, 5 Dec 2012 09:35:10 -0800

Just checking that I understand: If the RO == the issuer, then the RO == the AS, right? Just as in Nat's example, the user (or at least the device presenting a user agent to them) == the IdP? Colocating the RO and AS functions shouldn't be precluded, but I would be awfully confused if there were an RO/issuer in the picture and *also* an AS that *doesn't* issue assertions.

	Eve

On 5 Dec 2012, at 9:13 AM, Nat Sakimura <[email-masked]> wrote:

> It is not OAuth, but Austrian eID system is an example of RO as an assertion issuer pattern. They have their own SAML IdP on their PC (at least a few years ago) and combined with the qualified certs in the user's smart card and another file, creates a SAML assertion with sectoral identifier and supply it to other systems. 
> 
> Nat
> 
> On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell <[email-masked]> wrote:
> > > On Dec 3, 2012, at 6:06 PM, <[email-masked]> <[email-masked]
> > > > wrote: 
> > > 
> > > 
> > > +1. 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 5 Dec 2012 15:30:00 -0800

Most of the STS style usage I've seen has been using the SAML Bearer Token, rather than the JWT Bearer Token flow.   The predominant JWT usage I've seen thus far has been for self-issued assertions.

That said, the language in question is generalized to Assertion use-cases rather than a specific Assertion format.

-cmort

On Dec 5, 2012, at 6:48 AM, Lewis Adam-CAL022 wrote:

Hi Brian,

tx
adam

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, December 05, 2012 8:05 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

2012-12-04 23:41

收件人

抄送

主题

So, the clause becomes:

Nat

Nat

---

From: [email-masked]
Date: Thu, 6 Dec 2012 08:46:24 +0800

As I understand, RO=issuer  does not mean RO=AS.
RO as an issuer generates assertion (if the assertion is similar to 
delegation statement in my use cases),
AS as an assertion verifier receives the assertion and check its validity.

[email-masked] 写于 2012-12-06 01:35:10:

> Just checking that I understand: If the RO == the issuer, then the 
> RO == the AS, right? Just as in Nat's example, the user (or at least
> the device presenting a user agent to them) == the IdP? Colocating 
> the RO and AS functions shouldn't be precluded, but I would be 
> awfully confused if there were an RO/issuer in the picture and 
> *also* an AS that *doesn't* issue assertions.
> 
> Eve
> 
> assertion issuer pattern. They have their own SAML IdP on their PC 
> (at least a few years ago) and combined with the qualified certs in 
> the user's smart card and another file, creates a SAML assertion 
> with sectoral identifier and supply it to other systems. 
> 
> Nat

> On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell 
<[email-masked]
> any actual deployments supporting, or planning on supporting, RO as 
> an assertion issuer. 
> 

> Resource owner as an issuer is an interesting case but seems mostly 
> theoretical at this point.
> 
> I feel like mentioning the resource owner there in §5.1 would cause 
> more confusion than anything else. I'd prefer to just strike the 
> whole sentence in question and maybe add some additional text to §3 
> that clarifies that the issuer can really be any entity, if folks 
> think a change is needed here? 
> 
> 
> 

の

> > > >       material used to generate the assertion.  The issuer maybe 
either

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 6 Dec 2012 16:50:42 +0900

Here, I think it is better to differentiate the entity and function/role.

Authorization Server in OAuth is "kind of" entity.
Its function actually is split into two, or in most cases three.

1. Authentication Endpoint
2. Authorization Endpoint
3. Token Endpoint

Now, "Assertion Verifier" is a function/role. It is performed by 3. Token
Endpoint.
It check the validity, and issues access tokens (which in turn can be
another assertion by the way.)

Authorization Endpoint is another function. It can be located anywhere. In
your case, it is located in what you call as Resource Owner (Browser
plug-in?) In my Self-Issued IdP case, it is issued by the App in the phone
which is called by the custom schema.

This is the reason why I constantly grumble that it is better to speak in
terms of functions rather than entities.
Functions may reside in any entity, and if we talk only in terms of the
entities, the combination will explode.

Nat

On Thu, Dec 6, 2012 at 9:46 AM, <[email-masked]> wrote:

> > On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell <

---

From: Brian Campbell <[email-masked]>
Date: Thu, 6 Dec 2012 16:03:38 -0700

So to circle back to the original question/intent of this thread: the
assertion framework spec doesn't intended to constrain who/what can issue
the assertion. It does discuss some considerations for common (in the
authors' view anyway but I stand somewhat corrected by Nat) issuers and
that discussion might have been read as limiting who can issue.

Do folks think it reads as though it does constrain who/what can issue as
assertion for the flow? After rereading parts of it myself, I do think
there's some room for improvement in some of the text. But I don't know how
important it really is.

A question for the chairs or others more versed in the workings of the IETF
- is this document even in a place where changes can be made? The Shepherd
Write-Up for the document was recently sent to the IESG Secretary and I'm
honestly not sure what the protocol is for making changes at this point.

---

From: [email-masked]
Date: Fri, 7 Dec 2012 08:17:00 +0800

Brian Campbell <[email-masked]> 写于 2012-12-07 07:03:38:

> A question for the chairs or others more versed in the workings of 
> the IETF - is this document even in a place where changes can be 
> made? The Shepherd Write-Up for the document was recently sent to 
> the IESG Secretary and I'm honestly not sure what the protocol is 
> for making changes at this point.
Or we can start a new draft extending and clarifying the assertion 
document,
more use cases could be implemented by assertion may be included, and 
other things...

> Now, "Assertion Verifier" is a function/role. It is performed by 3. 
> Token Endpoint. 
> It check the validity, and issues access tokens (which in turn can 
> be another assertion by the way.)
> 
> Authorization Endpoint is another function. It can be located 
> anywhere. In your case, it is located in what you call as Resource 
> Owner (Browser plug-in?) In my Self-Issued IdP case, it is issued by
> the App in the phone which is called by the custom schema. 
> 
> This is the reason why I constantly grumble that it is better to 
> speak in terms of functions rather than entities. 
> Functions may reside in any entity, and if we talk only in terms of 
> the entities, the combination will explode. 
> 
> Nat
> 

> > > > > 2012/12/03 0:52、"[email-masked]" 
<[email-masked]> の
> > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" 
<[email-masked]> 
 
> > > > >       material used to generate the assertion.  The issuer 
> maybe either

---

From: Dick Hardt <[email-masked]>
Date: Fri, 7 Dec 2012 14:17:32 -0800

I am developing an implementation that will exchange a JWE for an Access Token.

Issuer will be a third party.

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 7 Dec 2012 22:50:43 +0000

JWE ?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Friday, December 7, 2012 2:18 PM
To: Chuck Mortimore
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

On Dec 5, 2012, at 3:30 PM, Chuck Mortimore <[email-masked]<mailto:[email-masked]>> wrote:

-cmort

Hi Brian,

tx
adam

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell

2012-12-04 23:41

收件人

抄送

主题

So, the clause becomes:

Nat

Nat