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<mailto:r...@ipv.sx>> wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley
<ve7...@ve7jtb.com<mailto: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<mailto: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<tel:%2B1%20%28858%29651-4478>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
