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

Brian Campbell <bcampbell@pingidentity.com> 写于 2012-12-20 04:26:03:

> 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?
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. 

> 
> On Mon, Dec 17, 2012 at 5:29 PM,  <zhou.sujing@zte.com.cn> wrote:
> >
> >
> > oauth-bounces@ietf.org 写于 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
> >>
> >> 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
> >
> > 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?
> >
> >
> >> 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
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >