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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Dec 2012 17:21:36 +0200

Hi all, 

I read through the mailing list discussion raised by Nat in this mail to the list on the 3rd of December, see http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html 

There were two types of issues:

1) The current text about the issuer (in Section 5.1 of <draft-ietf-oauth-assertions-08.txt> 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. 

There was, however, the perception that the current text, in the way it is worded, creates the impression that third party token services excludes entities like the resource owner. 

2) Some folks had the idea that the resource owner could create the assertion and they had a specific use case in mind. While this is not a currently deployed scenario (using OAuth technology) there seem to be some other deployment (the Austrian eID card deployment was mentioned by Nat) that could be re-build with this support in mind.

It seemed that just mentioning that the resource owner could create the assertion wouldn't be enough to understand the scenario. A more detailed writeup of the envisioned scenario would be needed but has not been provided to the mailing list. 

To me it seems that the best approach would be to do the following:  

a) to update the text in Section 5.1 as suggested by Nat in his mail http://www.ietf.org/mail-archive/web/oauth/current/msg10222.html

This by itself would not lead to any normative text change but may make it clear what the intention was. 

b) to encourage those who care about the use case where the resource owner creates the assertion to compile a document and to submit it to the group. This would allow us to evaluate whether all the required functionality is indeed available. 

Ciao
Hannes

---

From: [email-masked]
Date: Tue, 18 Dec 2012 08:29:41 +0800

[email-masked] 写于 2012-12-17 23:21:36:

> Hi all, 
> 
> I read through the mailing list discussion raised by Nat in this 
> mail to the list on the 3rd of December, see http://www.ietf.
> org/mail-archive/web/oauth/current/msg10203.html 
> 
> 1) The current text about the issuer (in Section 5.1 of <draft-ietf-
> oauth-assertions-08.txt> 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. 
> 
> There was, however, the perception that the current text, in the way
> it is worded, creates the impression that third party token services
> excludes entities like the resource owner. 
> 
> 2) Some folks had the idea that the resource owner could create the 
> assertion and they had a specific use case in mind. While this is 
> not a currently deployed scenario (using OAuth technology) there 
> seem to be some other deployment (the Austrian eID card deployment 
> was mentioned by Nat) that could be re-build with this support in mind.
> 
> It seemed that just mentioning that the resource owner could create 
> the assertion wouldn't be enough to understand the scenario. A more 
> detailed writeup of the envisioned scenario would be needed but has 
> not been provided to the mailing list. 
> 
> a) to update the text in Section 5.1 as suggested by Nat in his mail 
> http://www.ietf.org/mail-archive/web/oauth/current/msg10222.html

Nat's suggestion "Example of issuers include an OAuth client, resource 
owner, an independent third party."
there is still an issue,  "indenpendent" from who?  If  AS be an assertion 
issuer, could AS be called indenpendent? 

> b) to encourage those who care about the use case where the resource
> owner creates the assertion to compile a document and to submit it 
> to the group. This would allow us to evaluate whether all the 
> required functionality is indeed available. 
> 
> Ciao
> Hannes
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Tue, 18 Dec 2012 16:58:46 +0800

Hi,

> was mentioned by Nat) that could be re-build with this support in mind.

eID is for egovernment. May be it could, but the use case is in the scope 
of oauth. 

> not been provided to the mailing list. 
I have, but is buried in the mailing list, now I added modified usecases 
into 
a re-submitted document. 

> required functionality is indeed available. 

I have re-submitted a relevant document 
at http://tools.ietf.org/html/draft-zhou-oauth-owner-auth-01

---

From: Brian Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 13:26:03 -0700

They are just some examples and shouldn't limit who or what can be the issuer.

Maybe just removing that whole sentence that says, "The issuer may be
either an OAuth client (when assertions are self-issued) or a third
party token service.' would be better, if it's causing confusion?

---

From: [email-masked]
Date: Thu, 20 Dec 2012 08:32:56 +0800

> party token service.' would be better, if it's causing confusion?
It is causing confusion when entities in the oauth architecture are 
issuers. 
If the whole sentence is removed, similar sentences still exist in the 
following paragraphs,
confusion still exists.

How about a modification for 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."  (in  section 3 )
into 
 "The token service is the assertion issuer, it could be implemented in 
any entity besides client, including 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." 

And no more normative texts need to be changed.