I hope to be ready to post updated drafts incorporating the proposed
resolutions on Monday or Tuesday.
-- Mike
-Original Message-
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Saturday, October 11, 2014 2:42 PM
To: Mike Jones
Cc
-Original Message-
From: Ted Lemon [mailto:ted.le...@nominum.com]
Sent: Tuesday, October 07, 2014 10:30 AM
To: John Bradley
Cc: The IESG; Mike Jones; draft-ietf-oauth-json-web-to...@tools.ietf.org;
oauth-cha...@tools.ietf.org; oauth@ietf.org
Subject: Re: Ted Lemon's No Objection
Thanks for your review, Ted. I'm adding the working group to the thread so
they're aware of your comments.
-Original Message-
From: Ted Lemon [mailto:ted.le...@nominum.com]
Sent: Thursday, October 02, 2014 6:58 AM
To: The IESG
Cc: oauth-cha...@tools.ietf.org;
Thanks for your review, Tom. I've added the working group to this thread so
they're aware of your comment.
-Original Message-
From: Tom Taylor [mailto:tom.taylor.s...@gmail.com]
Sent: Sunday, September 28, 2014 8:33 PM
To: ops-...@ietf.org;
Thanks for your review, Meral. I've added the working group to this thread so
that they're aware of your comments.
From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
Sent: Monday, September 29, 2014 12:40 AM
To: draft-ietf-oauth-saml2-bearer@tools.ietf.org; gen-...@ietf.org
Thanks for your review, Radia. I've added the working group to the thread so
that they're aware of your comments.
From: Radia Perlman [mailto:radiaperl...@gmail.com]
Sent: Monday, September 29, 2014 4:46 PM
To: sec...@ietf.org; The IESG; draft-ietf-oauth-jwt-bearer@tools.ietf.org
Thanks for your review, Richard. My responses are inline below...
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, October 01, 2014 7:57 PM
To: The IESG
Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org;
Thanks for tracking all of this Stephen. Responses inline below...
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Monday, October 06, 2014 2:43 PM
To: Mike Jones; The IESG
Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web
-Original Message-
From: Ted Lemon [mailto:ted.le...@nominum.com]
Sent: Monday, October 06, 2014 12:49 PM
To: Mike Jones
Cc: The IESG; oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-
to...@tools.ietf.org; oauth@ietf.org
Subject: Re: Ted Lemon's No Objection on draft-ietf
Thanks for your review, Barry. I'm adding the working group so they’re aware
of these comments. At Stephen Farrell's request, I'm responding with line
prefixes on previous thread content. I'm also repeating (and in the first
case, augmenting) my previous responses to the DISCUSS comments
OK - I'll start prefixing my text with Mike .
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Thursday, October 02, 2014 8:49 AM
To: Mike Jones; Alissa Cooper; The IESG
Cc: oauth-cha...@tools.ietf.org;
draft-ietf-oauth-json-web-to...@tools.ietf.org
From: Mike Jones
Sent: Tuesday, September 23, 2014 3:51 PM
To: j...@ietf.org
Cc: Russ Housley; 'Roni Even'; 'Tero Kivinen'; 'Scott Kelly'; 'Stephen Kent';
'Charlie Kaufman'; 'Warren Kumari'; 'Tom Yu'; gen-...@ietf.org;
sec...@ietf.org; i...@ietf.org
Subject: JOSE -32 and JWT -26 drafts
Thanks again for your review, Warren. The resolutions discussed below have
been applied in the -26 draft.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, September 05, 2014 5:28 PM
FYI, the -32 and -26 drafts now use the terms Unsecured JWS and Unsecured
JWT.
-Original Message-
From: jose [mailto:jose-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, September 19, 2014 11:17 AM
To: Warren Kumari
Cc: sec...@ietf.org; Richard Barnes;
draft-ietf-oauth-json-web
Thanks for bringing this issue to our attention Tom, and for proposing its
resolution. This refinement has been added to the -26 draft.
-- Mike
-Original Message-
From: Tom Yu [mailto:t...@mit.edu]
Sent: Thursday, July 10, 2014 2:06 PM
To: Mike Jones
Cc
10:52 AM
To: Mike Jones
Cc: Richard Barnes; Brian Campbell;
draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org;
j...@ietf.org; sec...@ietf.org
Subject: Re: alternative term to plaintext for the none alg (was Re:
[OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)
On Wed, Sep 17
-json-web-algorithms-31#section-8.5
was added.
-- Mike
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Wednesday, September 17, 2014 4:40 AM
To: Richard Barnes
Cc: Brian Campbell; Mike Jones;
draft-ietf-oauth-json-web-token
You should not bring this to the working group, other than making people aware
that the disclosure exists (which you've already done). I know that I will
leave the room if the contents of a patent are discussed and I will encourage
others to likewise do so.
Engineers should not evaluate
+1
This gets it off the working group's plate and lets us gather data about
whether this useful or not and whether it's right or whether changes are
needed, based on actual usage experience.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, September 10,
Thanks for the useful review, Warren. I’m cc’ing the working group so they’re
aware of the contents of your review. Replies inline below…
-Original Message-
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Monday, September 01, 2014 3:40 PM
To: sec...@ietf.org;
Thanks for the review, Tom. I've cc'ed the OAuth working group so that they're
aware of the contents of your review.
-- Mike
-Original Message-
From: Tom Taylor [mailto:tom.taylor.s...@gmail.com]
Sent: Saturday, August 23, 2014 8:39 PM
To:
Here's some feedback on the document.
First, while I believe that the document is a good first working group draft
and this specification is important, it is not ready for last call, since there
are open issues called out in the document that have not been discussed by the
working group and
First, I’ll say that I appreciate Brian also working on this topic. This is
important for many multi-actor use cases and it would be good for OAuth to
develop a standard in this area. I also agree with the discussion on the list
that having some use case descriptions and concrete examples
Did you consider standardizing the access token format within that deployment
so all the parties that needed to could understand it, rather requiring an
extra round trip to an introspection endpoint so as to be able to understand
things about it?
I realize that might or might not be practical
Yes, but that’s the simplest thing to determine – try the token and see whether
it works or not.
From: Thomas Broyer [mailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: oauth@ietf.org; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call
.
-- Mike
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 21, 2014 12:00 PM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; Mike
Jones
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-05
.
-- Mike
From: Thomas Broyer [mailto:t.bro...@gmail.com]
Sent: Monday, July 21, 2014 1:47 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] FW: New Version Notification for
draft-hunt-oauth-v2-user-a4c-05.txt
The end of section 2.2
I agree with Brian’s suggested text. Thanks for writing this, Brian!
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Saturday, July 19, 2014 7:28 AM
To: Brian Campbell
Cc: oauth@ietf.org
I agree with Brian’s suggested text. Thanks for writing this, Brian!
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Saturday, July 19, 2014 7:24 AM
To: Brian Campbell
Cc: oauth@ietf.org
formats.)
-- Mike
-Original Message-
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Wednesday, July 16, 2014 4:53 AM
To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
I like the idea
There will be an OpenID meeting at IETF 90 on Sunday from 1-4. If you're
interested, please register at http://openid-ietf-90.eventbrite.com/.
-- Mike
___
OAuth mailing list
OAuth@ietf.org
think we could reference 3 and 4 as examples to be safe.
John B.
On Jul 8, 2014, at 3:04 PM, Mike Jones michael.jo...@microsoft.com wrote:
Was there specific language that had been discussed to be added for this?
If not, could someone please create some
Fine with me. (I might change the privacy policy to the site's privacy
policy.)
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, July 14, 2014 4:25 AM
To: John Bradley; Mike Jones
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG
, 2014 10:45 AM
To: Mike Jones; Brian Campbell; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
Hi Mike,
sticking with working group document is fine.
However, the first example does not make sense to me.
[maybe my brain is a bit empty
Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, July 14, 2014 10:57 AM
To: Mike Jones; Brian Campbell; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
That would then be a reference to an individual draft ;-)
On 07/14/2014 07:55 PM, Mike
I believe that client_secret_expires_at was a signal to clients that they
should plan on retrieving a new client_secret value around that time. That
makes sense if you have the management protocol to do so, but I agree with you
that it isn't very useful without it. Maybe it should be moved to
I likewise do not hold any IPR on these specs.
From: Phil Huntmailto:phil.h...@oracle.com
Sent: 7/8/2014 9:11 AM
To: Hannes Tschofenigmailto:hannes.tschofe...@gmx.net
Cc: Mike Jonesmailto:michael.jo...@microsoft.com; John
Bradleymailto:ve7...@ve7jtb.com; Justin
I agree with Nat’s assessment. I’m fine updating the textual description of
the parameter, but we should not consider breaking changes to the parameter
names at this point.
Do you have specific wording in mind, Hannes?
-- Mike
From:
Was there specific language that had been discussed to be added for this? If
not, could someone please create some?
Thanks,
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes
I put it back because otherwise, we wouldn't be meeting one of the requirements
of the RFC 6749. If you look at the client registration section
http://tools.ietf.org/html/rfc6749#section-2, you'll see that registering
redirect_uri values is required, as is registering the client type. Without
, provided that attribution be made
to the OIDF as the source of the material, but that such attribution does not
indicate an endorsement by the OIDF.
Let’s add the reference and acknowledgment in the next version.
-- Mike
From: Mike Jones
That's close but not quite right, since use is required by clients when using
redirect-based grant types. We could however, use this language:
The implementation and use of all client metadata fields is OPTIONAL, other
than redirect_uris
which is REQUIRED for authorization servers that
I’d like 10-15 minutes of agenda time to discuss this draft:
·http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01
I support Nat presenting the two drafts below and the rest of the agenda
suggestions that have been made.
I believe we should have an all-up discussion on the
From: Mike Jones
Sent: Friday, July 04, 2014 4:31 PM
To: j...@ietf.org
Subject: JOSE -31 and JWT -25 drafts addressing additional AD comments
In preparation for IETF 90 in Torontohttp://www.ietf.org/meeting/90/, I've
published yet another round of small deltas to the JOSE and JWT
Done
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Thursday, July 03, 2014 12:59 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD
feedback on fifth spec of five
On Thu, Jul 3, 2014 at 3:38 PM, Mike Jones
In preparation for IETF 90 in Torontohttp://www.ietf.org/meeting/90/, I've
updated the OAuth Token Exchange draft to allow JWTs to be unsigned in cases
where the trust model permits it. This draft also incorporates some of the
review feedback received on the -00 draft. (Because I believe it
In preparation for IETF 90 in Torontohttp://www.ietf.org/meeting/90/, I've
update the JWT Proof-of-Possession specification. The changes are mostly
editorial in nature, plus a few changes that hadn't received adequate review
prior to inclusion in the -01 draft were reverted.
This
Replies inline…
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Thursday, July 03, 2014 11:56 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD
feedback on fifth spec of five
Hello!
Thank you for all
An updated OAuth Dynamic Client Registration spec has been published that
clarifies the usage of the Initial Access Token and Software Statement
constructs and addresses other review feedback received since the last version.
See the History section for more details on the changes made.
The
[mailto:internet-dra...@ietf.org]
Sent: Thursday, July 03, 2014 3:11 PM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; Mike
Jones
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-04.txt
A new version of I-D, draft-hunt-oauth-v2-user-a4c-04.txt
has been
From: Mike Jones
Sent: Tuesday, July 01, 2014 6:11 PM
To: j...@ietf.org
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of
five
JOSE -30 and JWT -24 drafts have been posted incorporating improvements
resulting from Kathleen Moriarty's JWE review. At this point
From: Mike Jones
Sent: Friday, June 20, 2014 4:52 PM
To: j...@ietf.org
Subject: JOSE -28 and JWT -22 drafts incorporating additional AD feedback
Updated JOSE and JWT drafts have been released that incorporate additional
wording improvements in places suggested by Kathleen Moriarty. Most
From: Mike Jones
Sent: Friday, June 20, 2014 10:42 PM
To: j...@ietf.org
Subject: JOSE -29 and JWT -23 drafts coalescing duplicative terminology
definitions
Surprise! For the first time ever, I've released two sets of JOSE and JWT
drafts in one day! I wanted to separate the changes
Actually, there is a very clear definition of what the minimal Mandatory To
Implement (MTI) in OpenID Connect is - it's right in the spec. See the (quite
short) sections:
15.1.http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
Mandatory to Implement Features for All OpenID
[mailto:prateek.mis...@oracle.com]
Sent: Friday, June 13, 2014 9:55 AM
To: Mike Jones; Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Mike - when i see language like
[quote]
This list augments the set of features that are already listed elsewhere
considerations section.)
-- Mike
From: Mike Jones
Sent: Monday, June 09, 2014 5:32 PM
To: j...@ietf.org
Cc: Kathleen Moriarty
Subject: Proposed Security Considerations sections changes
In response to Kathleen's requests to beef up the security
, this draft uses
only the standard OAuth 2.0 endpoints.
-- Mike
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, May 28, 2014 8:52 AM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin
A new version of the OAuth Dynamic Client Registration specification has been
published that folds the client metadata definitions back into the core
registration specification, as requested by the working group. The updated
spec is clear that the use of each of the defined client metadata
The acr claim (authentication context class reference) and the acr_values
request parameter are explicitly modelled on the SAML authentication context
work, but without the more complicated parts that didn't work out well in
practice. In this case, the request is just an ordered list of
Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE)
specifications were granted a Special European Identity Award for Best
Innovation for Security in the API Economy. I was honored to accept the award,
along with Nat Sakimura and John Bradley, on behalf of the
Forwarding to the mailing list, since I mistakenly replied only to Hannes...
-Original Message-
From: Mike Jones
Sent: Thursday, April 24, 2014 2:44 PM
To: 'Hannes Tschofenig'
Subject: RE: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up
I am not aware of any IPR
The JOSE -26 and JWT -20 drafts address a few editorial issues recently
identified by reviewers, hopefully further clarifying these aspects of the
specifications. No normative changes were made.
See the Document History entries for details on the specific changes made.
The specifications are
of the UTF-8 encoding also supplied are
authoritative for these examples.
Thanks again for the useful feedback.
-- Mike
-Original Message-
From: Mike Jones
Sent: Monday, April 28, 2014 8:48 AM
To: Hannes Tschofenig; Brian Campbell
Cc: oauth@ietf.org
Subject
Hi Hannes,
I have the changed the RFC 6755 and JWK references in
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-20 in the manner
that you suggested.
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes
I'm not opposed to saying more about the fact that in order to verify the
examples, people need to use the octet sequence representation, rather than the
ASCII representation, since aspects of the ASCII rendering will vary, including
whether lines are terminated by CRLF or LF sequences and in
://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#appendix-A.2 is
protected by a digital signature (and then encrypted).
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, April 28, 2014 1:39 AM
To: Mike Jones; Brian Campbell
Cc: oauth@ietf.org
Subject: Re
I’m not sure how octal came up, as the examples all use JSON notation, which is
decimal. (The word octet is a standard word for a value containing 8 bits, and
has nothing to do with octal.)
Hannes, we use JSON notation in the examples, rather than hexadecimal
intentionally, as the specs are
I agree. We’d already discussed this pretty extensively and reached the
conclusion that always requiring both an issuer and a subject both kept the
specs simpler and was likely to improve interoperability.
It’s entirely up to the application profile what the contents of the issuer and
the
To be clear, access tokens are opaque in OAuth and I don’t see any of us trying
to change that in the general case. Particular authorization servers may use
JWTs as an access token format, but that’s their private choice. I know of
other authorization servers that have the access token value
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Thursday, April 24, 2014 1:57 AM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Minor questions regarding
draft-ietf-oauth-json-web-token-19
Thanks, Mike.
Leave the ECMAScript reference
I am aware of these implementations:
Microsoft Azure Active Directory:
http://azure.microsoft.com/en-us/services/active-directory/
Google Service Account:
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
I believe that Ping Identity and Salesforce also have
Thanks for doing the write-up, Hannes. I would suggest that the following
changes be made in the write-up:
Change This document belongs to the OAuth assertion document bundle consisting
of the abstract OAuth assertion framework, and the SAML assertion profile to
This document belongs to the
The assertions draft is only trying to describe how to perform assertion-based
authentication at the Token Endpoint. Other drafts, such as the introspection
draft, could explicitly say that this can also be done in the same manner
there, but that's an extension, and should be specified by the
I am not aware of any IPR that applies to this specification.
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 23, 2014 1:40 AM
To: oauth@ietf.org
Subject: [OAUTH-WG]
The new http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00
specification defines a way to compute a thumbprint for a JWK (or in fact, any
key with a defined JWK representation).
-- Mike
From: OAuth
for it...
-- Mike
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Saturday, April 12, 2014 6:12 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
Good start here Mike!
One
Can you sketch out what data structures you'd ideally use for your scenario and
what the elements mean?
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Saturday, April 12, 2014 8:39 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON
Am I correct that there were no working group last call comments received on
draft-ietf-oauth-jwt-bearer? (It's possible that I missed them, of course...)
If so, it sounds to me like nothing blocks this from proceeding to IESG review
beyond the JWT and Assertions spec dependencies. Is that
The core spec actually already does speak to this question, Bill.
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16#section-3 says:
In some cases, authorization servers MAY choose to accept a software
statement value directly as a Client ID in an authorization request,
without a
If the working group decides to merge these specs, I'd be happy to do the
editorial work to do so.
Best wishes,
-- Mike
-Original Message-
From: Anthony Nadalin
Sent: Saturday, April 05, 2014 4:06 PM
To: Mike Jones; Hannes
As a point of clarity, OpenID Connect does not mandate support for dynamic
registration in all cases. In static profiles with a pre-established set of
identity providers, it isn’t required. It *is* required in the dynamic
profile, in which clients can use identity providers that they have no
OpenID Connect defines how it happens for OpenID Connect. Other dynamic OAuth
use cases still definitely need this.
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Sunday, April 06, 2014 10:49 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic
I would combine these two documents, with no normative changes. This would be
a convenience for implementers. And the metadata values that are currently
optional would remain optional.
I would also add an optional jwks metadata member, paralleling this addition
in OpenID Connect
I agree with what John wrote below. Besides, PoP is more natural to say than
HoK and certainly more natural to say than HOTK. I'd like us to stay with the
term Proof-of-Possession (PoP).
-- Mike
From: OAuth
Thanks for the comments, James. Comments inline marked with Mike.
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, April 02, 2014 6:45 AM
To: Manger, James
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics
I've written a concise Internet-Draft on proof-of-possession for JWTs with John
Bradley and Hannes Tschofenig. Quoting from the abstract:
This specification defines how to express a declaration in a JSON Web Token
(JWT) that the presenter of the JWT possesses a particular key and that the
This typo has been corrected in the JOSE -25 specs. Thanks for bringing it to
our attention.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Antonio Sanso
Sent: Sunday, March 30, 2014 11:44 PM
To: John Bradley
Cc:
I've released updated versions of the OAuth Assertions, OAuth SAML Assertion
Profile, and OAuth JWT Assertion Profile specs that use current citations for
the other specs they reference, including the JSON, JWT, OAuth Dynamic
Registration, and OpenID Connect specs. I also improved the
JOSE -24 drafts have been released that fix two errors found in example values.
The JWT -19 draft clarifies that support for Nested JWTs is optional. The
JSON reference was also updated to RFC 7159 in all drafts.
The specifications are available at:
*
I also disagree with moving scope into the core registration spec. The
metadata values in the core spec are those that are essential to use to achieve
registration. Those in the metadata spec are those that are useful in some
applications but not needed by some others. scope is of the second
To this, I'll add that the OpenID Connect ID Token specification at
http://openid.net/specs/openid-connect-core-1_0.html#IDToken adds this,
prohibiting the use of header parameters to communicate the keys:
ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk header parameter
fields.
Hi Hannes and WG,
I just did what you had asked - sending detailed replies to everyone who had
sent JWT WGLC comments. I'd addressed most of the comments earlier but
discovered a few requested clarifications that I hadn't incorporated yet -
hence the -18 release just now. As you can see from
Hi Prateek,
Thanks for taking the time to send in these comments. I am sending you this to
describe the changes that were made in response to your comments (mostly in -13
but also a few in -18). See individual responses inline.
Thanks for taking the time to send in the comments, James. I am sending you
this to describe the changes that were made in response to your comments
(mostly in -13 but also a few in -18). See individual responses inline.
-- Mike
Thanks for your useful comments, Brian. See my replies inline.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Campbell
Sent: Friday, November 01, 2013 12:53 PM
To: Tschofenig, Hannes (NSN -
Hi Hannes,
My replies to your comments follow in-line. Thanks again for writing these up.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Tschofenig, Hannes (NSN -
Draft -18 of the JSON Web Token (JWT) spec has been released, which addresses
the few remaining outstanding comments from Working Group Last Call (WGLC).
All edits were clarifications, rather than normative changes. See the Document
History appendix for a description of the changes made.
New
Updated JOSE and JWT drafts have been published that fix a few instances of
incorrect uses of RFC 2119 requirements language, such as changing an
occurrence of MUST not to MUST NOT. These drafts also reference the newly
completed JSON specification - RFC 7158http://tools.ietf.org/html/rfc7158.
The only JWT change was to change some normative references to being
non-normative, paralleling companion changes made in the JOSE specifications.
-- Mike
From: Mike Jones
Sent: Friday, February 14, 2014 5:06 PM
To: j...@ietf.org
There are now OAuth working grouphttp://datatracker.ietf.org/wg/oauth/
versions of the refactored OAuth Dynamic Client Registration specifications:
*OAuth 2.0 Dynamic Client Registration Core Protocol
*OAuth 2.0 Dynamic Client Registration Metadata
*OAuth 2.0 Dynamic
501 - 600 of 1018 matches
Mail list logo
