+1 On Oct 17, 2014, at 3:23 PM, Brian Campbell <bcampb...@pingidentity.com> 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 <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/> >> 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
