Hi Mike,
thanks for the clarifications. My comments are addressed.
Ciao
Hannes
On 03/03/2014 11:22 PM, Mike Jones wrote:
Hi Hannes,
My replies to your comments follow in-line. Thanks again for writing
these up.
--
Hi all,
in preparing the shepherd write-up for draft-ietf-oauth-jwt-bearer-08 I
had to review our recent email conversations and the issue raised by
Antonio in
http://www.ietf.org/mail-archive/web/oauth/current/msg12520.html belong
to it.
The issue was that Section 3 of
Hi all,
in a discussion about re-using the client authentication part of the
assertion framework for other specifications currently in progress I ran
into the following question:
Section 6.1 of
http://tools.ietf.org/html/draft-ietf-oauth-assertions-15 talks about
the client using the assertion
Hi all,
here are a few comments regarding the draft-ietf-oauth-dyn-reg-16 spec.
The first two are editorial and a matter of taste.
- Abstract
The abstract is awfully short. Could you at least add a few more lines
to tell the reader what to expect in the document?
- Introduction
I believe the
Responses inline.
On 04/23/2014 09:08 AM, Hannes Tschofenig wrote:
Hi all,
here are a few comments regarding the draft-ietf-oauth-dyn-reg-16 spec.
The first two are editorial and a matter of taste.
- Abstract
The abstract is awfully short. Could you at least add a few more lines
to tell 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
For introspection, we really just wanted to say you can authenticate
the caller (client or RP) just like you would to the token endpoint. So
if you've got the means to do that with the assertion draft or with
client secrets or TLS certs or anything else, go for it. I would not
read the text of
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]
Hi all,
I read through the document as part of my shepherding task; it is nicely
written and easy to understand.
I only have a few minor suggestions:
* client_uri: URL of the homepage of the client.
Would it be better to say that this is the URI provides further
information about the client
Thank you for the review, responses inline (and this draft still needs
to be factored back into the main one):
On 04/23/2014 03:14 PM, Hannes Tschofenig wrote:
Hi all,
I read through the document as part of my shepherding task; it is nicely
written and easy to understand.
I only have a few
That thread that Antonio started which you reference went on for some time (
http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520) and
seems to have reached consensus that the spec didn't need normative change
and that such privacy cases or other cases which didn't explicitly need
While OAuth access tokens are a valuable application of JWT, might it also
be worthwhile to mention that JWT can and will be useful in other contexts?
Connect's ID Token is one such example:
http://openid.net/specs/openid-connect-core-1_0.html#IDToken
On Wed, Apr 23, 2014 at 5:55 AM, Hannes
Just to pile on here - the Assertions draft(s) do define client assertion
authentication only for the token endpoint (and register token endpoint
parameters). But it certainly doesn't preclude it from being profiled for
use elsewhere.
FWIW we used the token endpoint in our implementation of token
13 matches
Mail list logo
