[OAUTH-WG] Fwd: Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS)

[Brian Campbell <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>



On Thu, Oct 16, 2014 at 7:42 AM, Ted Lemon <[e-mail]> wrote:

> On Oct 16, 2014, at 8:37 AM, Brian Campbell <[e-mail]>
> 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?