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

[John Bradley <[e-mail]>]

+1
On Oct 17, 2014, at 3:23 PM, Brian Campbell <[e-mail]> wrote:

> 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/>
>> Qualcomm Technologies, Inc. - [phone]
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
>