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 protected]> 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 protected]>
> wrote:
> 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 protected]> wrote:
>
> Why RO as an issuer is only theoretical today?
>
>
>
> Brian Campbell <[email protected]>
> 2012-12-04 23:41
>
> ??????
> Nat Sakimura <[email protected]>
> ????
> [email protected], "[email protected]" <[email protected]>
> ????
> 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 protected]> 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.
>
> 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 protected]> wrote:
>
>
>
> Chuck Mortimore <[email protected]> ???? 2012-12-04 10:26:50:
>
>
> > 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.
>
> 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 protected]> wrote:
> >
> >
> > Obviously, it is not so clear from the language there.
> >
> >
> > Chuck Mortimore <[email protected]> ???? 2012-12-04 10:17:12:
> >
> > > There's no reason why it can't be resource owner today.
> > >
> > > On Dec 3, 2012, at 6:06 PM, <[email protected]>
> > > <[email protected]
> > > > wrote:
> > >
> > >
> > > +1.
> > > And why it was not looked at that time?
> > >
> > > [email protected] ???? 2012-12-04 01:30:55:
> > >
> > > > 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:
> > > > 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
> > > clearlydefining.
> > > > I had similar experience in other fora.
> > > >
> > > > Nat
> > > >
> > > > Sent from iPad
> > > >
> > > > 2012/12/03 0:52??"[email protected]" <[email protected]> ??
> > > > ???????`??:
> > >
> > > >
> > > > could be Resource owner?
> > > >
> > >
> > > >
> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <[email protected]>
> > > > ??????: [email protected]
> > > > 2012-12-03 16:49
> > > >
> > > > ??????
> > > >
> > > > "ext Nat Sakimura" <[email protected]>, "Brian Campbell" <
> > > > [email protected]>, "oauth" <[email protected]>
> > > >
> > > > ????
> > > >
> > > > ????
> > > >
> > > > 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 protected] [mailto:[email protected]] 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,
> > > >
> > > >
> > > > 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)
> > > residingin 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
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > >
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > _______________________________________________
> > > OAuth mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
