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 <r...@ipv.sx> wrote: > On Fri, Oct 17, 2014 at 10:32 AM, John Bradley <ve7...@ve7jtb.com> 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 <presn...@qti.qualcomm.com> >> 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. - +1 (858)651-4478 >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
