Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes <[e-mail]>]

On Fri, Oct 17, 2014 at 10:32 AM, John Bradley <[e-mail]> wrote:

> I think this part of sec 3 of assertions states that:
>
>  The protocol parameters and processing rules defined in this document
>    are intended to support a client presenting a bearer assertion to an
>    authorization server.  The use of holder-of-key assertions are not
>    precluded by this document, but additional protocol details would
>    need to be specified.
>
>
>
> As part of defining the additional protocol details for holder-of-key/PoP
> we can relax the must for audience in the profile that defines how to use
> those assertion types.
>

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials
here?  The entire remainder of the spec is written as if they didn't
exist.  And as the text above notes, you can't actually use them with this
specification.

If we're going to keep the mention, could we augment the text above to make
it clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""

--Richard




>
> John B.
>
> On Oct 17, 2014, at 2:25 PM, Pete Resnick <[e-mail]>
> wrote:
>
>  On 10/17/14 12:09 PM, Mike Jones wrote:
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
> Do you mean you shouldn't consider making it optional for HoK? Again,
> making it clear that the MUST applies only to bearer assertions, and that
> future extensions for HoK might have different requirements, is all that is
> being asked for here.
>
> pr
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - [phone]
>
>
>