Looks good to me, thanks. I cleared. --Richard On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones <michael.jo...@microsoft.com> 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:bcampb...@pingidentity.com] > *Sent:* Friday, October 17, 2014 8:23 AM > *To:* Richard Barnes > *Cc:* John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete > Resnick; oauth; The IESG; oauth-cha...@tools.ietf.org > *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 <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
