From: Mike Jones
Sent: Friday, October 17, 2014 6:32 PM
To: j...@ietf.org
Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments
I've posted updated JOSE and JWT drafts that address the Applications Area
Directorate review comments. Thanks to Ray Polk and Carsten Bormann for t
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : JSON Web Token (JWT)
Authors : Michael B. Jones
John Bradley
Stephen,
I'm working on updating these drafts and as I look again at the text that's
in §5. Interoperability Considerations and the requirement in §3 Assertion
Format and Processing Requirements to compare these values using the Simple
String Comparison (absent an application profile specifying ot
I agree with mike that any additional guidance on when you'd want to use an
assertion for client authentication vs. when you would want to use one for
an authorization grant would belong in the generic assertions specification
draft-ietf-oauth-assertions.
I'm struggling with what guidance to give
+1
On Oct 17, 2014, at 3:23 PM, Brian Campbell 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
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.or
On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell
wrote:
>
>
> On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes wrote:
>
>>
>>
>> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Thanks for your review and feedback on this one too, Richard. Replies
>>>
It's a known set of actual attacks ... on bearer assertions. There is no
corresponding attack on HoK assertions.
We shouldn't consider making it optional for bearer assertions. For HoK,
there's no reason for it not to be optional.
On Fri, Oct 17, 2014 at 10:09 AM, Mike Jones
wrote:
> +1
>
>
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley 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
I just caught up on the thread again and think Brian's message below may be the
most helpful to resolve this discuss.
It sounds like we have agreement that a MUST is preferred for bearer tokens and
that's what this draft is about. Would a language tweak help when HoK is
mentioned? The WG wi
FWIW…I was only responding to the question of making aud optional for bearer
tokens.
The broader point is that regardless of token type, there is always an “aud”
value — whether explicitly declared as a claim, or implicitly implied (e.g.
through encryption so only the audience can consume it).
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,
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,
+1
This is the standard mitigation for a known set of actual attacks. We
shouldn't even consider making it optional.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, October 17, 2014 9:50 AM
I believe that if you make “aud” optional, it only helps the simplistic
deployment scenarios where there is only one RS and one AS. The optionality
itself will cause more confusion. In the simplistic case, the AS and RS simply
have to agree on a URI.
In more sophisticated domains where there i
Touché... ;)
On Thu, Oct 16, 2014 at 4:36 PM, Richard Barnes wrote:
> That's what you get for duplicating all the text :)
>
> On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> Basically the same response to the basically same question as from
>> http://w
On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes wrote:
>
>
> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> Thanks for your review and feedback on this one too, Richard. Replies
>> are inline below...
>>
>> On Wed, Oct 15, 2014 at 10:01 PM, Richard Bar
I am good with it as is. I think we have the flexibility to add HoK later.
I mostly wanted to point out that it is really only in that later HoK profile
where omitting audience is safe.
If I had the power to remove the DISCUS I would.
John B.
On Oct 17, 2014, at 12:56 PM, Brian Campbell
These drafts define the use of bearer assertions. The only mention of HoK
style assertions is at the end of
https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which
notes that the "rules defined in this document are intended to support a
client presenting a bearer assertion to an
Hi
On 17/10/14 16:13, John Bradley wrote:
Are you saying that the OIDC filter/client can set session cookies in a domain
that other web servers can use, so they don't have to have any direct knowledge
of Connect.
Yes. It is a pity I was not able to express myself with a single
sentence like y
Hi,
On 17/10/14 16:11, Richer, Justin P. wrote:
On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin wrote:
Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:
- should a few words be reserved for the client credentials flow - this is of
course not a mainstream OAuth2 nor its related to OIDC but it i
Are you saying that the OIDC filter/client can set session cookies in a domain
that other web servers can use, so they don't have to have any direct knowledge
of Connect.
I suspect that is a common practice in many SSO implementations. It is true
that not every web server needs to implement c
On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin wrote:
> Hi,
> On 17/10/14 15:09, Richer, Justin P. wrote:
> - should a few words be reserved for the client credentials flow - this
> is of course not a mainstream OAuth2 nor its related to OIDC but it is
> all about the authenticatio
Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:
- should a few words be reserved for the client credentials flow - this is of
course not a mainstream OAuth2 nor its related to OIDC but it is all about the
authentication IMHO, the clients get their tokens by simply getting
authenticated, and as
>>> - should a few words be reserved for the client credentials flow - this is
>>> of course not a mainstream OAuth2 nor its related to OIDC but it is all
>>> about the authentication IMHO, the clients get their tokens by simply
>>> getting authenticated, and as far as legacy (code) clients are
Hi,
On 17/10/14 14:33, Richer, Justin P. wrote:
On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin wrote:
+1. I'm finding this write-up summarizing the "OAuth2 and Authentication"
'situation' perfectly. It does help.
Minor suggestions/questions:
- might make sense to point out that an id_token ca
On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin wrote:
> +1. I'm finding this write-up summarizing the "OAuth2 and Authentication"
> 'situation' perfectly. It does help.
>
> Minor suggestions/questions:
> - might make sense to point out that an id_token can be linked to the access
> token (via a
+1. I'm finding this write-up summarizing the "OAuth2 and
Authentication" 'situation' perfectly. It does help.
Minor suggestions/questions:
- might make sense to point out that an id_token can be linked to the
access token (via at_hash), thus confirming both tokens came from the
same AS
- shou
28 matches
Mail list logo
