I realized that I'd accidentally replied only to Ted in this thread (email is hard!). So I wanted to send our discussion to the original cc list so it'd be more on the record and also because I believe this discussion is related to, and may help inform, some other comments that came in this morning.
---------- Forwarded message ---------- From: Brian Campbell <bcampb...@pingidentity.com> Date: Thu, Oct 16, 2014 at 8:34 AM Subject: Re: [OAUTH-WG] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS) To: Ted Lemon <ted.le...@nominum.com> On Thu, Oct 16, 2014 at 7:42 AM, Ted Lemon <ted.le...@nominum.com> wrote: > On Oct 16, 2014, at 8:37 AM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > It's a good question Ted, thanks for your review. The concern is > mitigated by the requirement in ยง5.2 (third bullet > https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-5.2) > which requires that these bearer assertions be audience restricted. > Assertions with audience restrictions can only be used at the specific > relying party(s) to whom they were addressed. > > > > So I think the concern is addressed in processing rules of the draft. > But do you think it should also be mentioned in the security considerations? > > Hm, interesting. I didn't connect that, because I assumed that while a > bearer assertion could be issued for a particular relying party, other > assertions might be issued for other relying parties using the same token. > This could be either because of some policy on the client, or because the > end-user just types in the same token in several places, as is > unfortunately common practice with user passwords. > > So I guess I think a bit more discussion is warranted, but it may be that > my concern is based on a misunderstanding of how bearer assertions are > generated, in which case the discussion may not be necessary. So I guess > the question is, am I misunderstanding something here that makes this > concern not an issue? > > Typically an assertion will be issued for use at a specific relying party in a specific context (like one of these profiles or for web single sign-on) . And it will be time limited to something on the order of minutes or maybe hours but not longer. The assertion is the token. It carries information about the user and how they authenticated (how is not dictated here but the assertion can describe it to the relying party) with the assertion issuer. But it's not something that the user would ever type in or even see or be aware of in most cases. The audience restriction let's the issuer say specifically what relying party is allowed to consume the assertion, which ensures that the client can't use it somewhere that it wasn't intended and that the relying party that receives the assertion can't turn around and use it to access some other service. Is this helping your understanding or just confusing matters?
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
