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

[Richard Barnes <[e-mail]>]

Looks good to me, thanks.  I cleared.
--Richard

On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones <[e-mail]>
wrote:

>  Richard, yours are the only discusses on draft-ietf-oauth-assertions,
> draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re
> all about the audience requirement. Brian added text addressing this in
> the last paragraph of
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.
> Are you willing to clear these DISCUSSes on this basis?
>
>
>
> If not, can we try to talk before the OAuth meeting tomorrow morning?
> I’ll be leading the assertions drafts discussions tomorrow since Brian
> won’t be able to attend.
>
>
>
>                                                             Thanks,
>
>                                                             -- Mike
>
>
>
> *From:* Brian Campbell [mailto:[e-mail]]
> *Sent:* Friday, October 17, 2014 8:23 AM
> *To:* Richard Barnes
> *Cc:* John Bradley; [e-mail]; Pete
> Resnick; oauth; The IESG; [e-mail]
> *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> That text works for me, Richard. Thanks.
>
> I will go with Richard's text in the next draft, unless I hear objections.
>
>
>
> FWIW, the mention of HoK was a result of a review and suggestions from
> Hannes some time ago.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt
>
>
>
> It could be removed, to your point, but I think your proposed text is very
> clear about the scope and might help prevent confusion.
>
>
>
>
>
> On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes <[e-mail]> wrote:
>
> 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]
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>