Regarding the comment on Section 2, I had originally argued for the
inclusion of ASCII(xxx) as I felt it was important to avoid potential
ambiguity that was in the draft at the time (it wasn't 100% clear to me at
the time if the code_verifier was to be base64url decoded as input into the
hash or
Sorry to dig this back up but am I naive to wonder why anyone would even use
JSONP. Sounds like the hackiest legitimate thing I've ever seen, and asking for
trouble to use it.
-William
From: Justin Richer jric...@mit.edumailto:jric...@mit.edu
Date: Monday, June 29, 2015 at 11:36 AM
To: Nat
hi Aaron
On Jul 7, 2015, at 6:23 AM, Aaron Parecki
aa...@parecki.commailto:aa...@parecki.com wrote:
Section 5.2 lists the possible errors the authorization server can return for
an access token request. In the list is invalid_scope, which as I understand
it, can only be returned for a
Speaking as someone who is reasonably familiar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
I'm just catching up on this tread, but would appreciate an in-room
discussion on this topic that doesn't assume the adopted draft has the
agreed upon approach as I am not reading that there is consensus on that
approach in this thread at all.
Could we see presentations on Mike's draft and
Kathleen,
I agree that Brian’s approach covers the use case that drove my original draft
and effectively subsumes my approach.
My standing contention with the document as it stands is and has always been
that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I
would love
I’ll write a note later today describing how the just-published update that
makes the Token Exchange draft token-type agnostic also enables it to be used
in fully “OAuthy” cases – where some of the tokens used are OAuth access tokens
or refresh tokens.
(Right now I’m writing up the changes
On Tue, Jul 7, 2015 at 3:43 PM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:
I'm just catching up on this tread, but would appreciate an in-room
discussion on this topic that doesn't assume the adopted draft has the
agreed upon approach as I am not reading that there is consensus
Thanks Barry,
These are the issues that I wanted to discuss with John before making
change.
-- Section 6.2 -- John has partly addressed your IANA comment already. I
needed
to check if there was any reason for just doing partly.
-- Section 7.2 -- is probably just my oversight. I will deal with
The editors have published
draft-ietf-oauth-proof-of-possession-03https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03,
which addresses the working group last call comments received. Thanks to all
of you who provided feedback. The changes were:
* Separated the jwk and
Thanks for your responses on these comments.
I can approve an updated draft to make this change and the one for IANA if
that is the easiest path. The other option is to write this all up in an
RFC editor note and I can send that with the approval. Making the direct
updates may be simpler to
Draft -02 of the OAuth 2.0 Token Exchange specification has been published,
making the functionality token type independent. Formerly, only JSON Web
Tokens (JWTs) could be used in some contexts. This was a change requested by
working group participants during IETF 92 in Dallas.
The
In sec 6 you can send scope to down scope a refresh token.
In that case if the client asks for a scope that was not part of the original
code grant then you would return invalid_scope.
It is not an error in the spec.
Regards
John B.
On Jul 7, 2015, at 11:42 AM, Aaron Parecki
Thanks, the refresh grant was the case I was missing.
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Tue, Jul 7, 2015 at 8:13 AM, John Bradley ve7...@ve7jtb.com wrote:
In sec 6 you can send scope to down scope a refresh token.
In that case if the client asks for
I have a draft with Barry’s edits less the removal of ASCII(string) ready to go.
In JWS we used ASCII(string) to indicate that the output is a sequence of
octets, strings are not necessarily 8 characters bits and may have null
termination etc.
However as Brian states other changes may have
I’m not sure how Brian’s approach solves the basic generic token exchange use
case that we have
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 7, 2015 4:47 PM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth@ietf.org oauth@ietf.org
Subject: Re:
As just updatedhttp://self-issued.info/?p=1412, I believe that the working
group token exchange draft
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also
serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token
chaining use case, as well as support
In JWS we used ASCII(string) to indicate that the output is a sequence of
octets, strings are not necessarily 8 characters bits and may have null
termination etc.
However as Brian states other changes may have removed the need for that.
I admit saying where STRING is a sequence of zero or
This approach is not a good fit for my use cases, and it’s still not OAuth-y
at all. It requires a specially-formed security assertion on the way in, which
the client must understand and generate. I still can’t take an arbitrary token
I’ve been handed by someone else and pass it off to be
I’ll start by saying that if you compare
https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly,
you’ll find a lot in common. Both have requests and responses formatted using
JSON objects, both have input and
Thanks, I fixed my finger dyslexia for the next draft.
I changed it to t_m rather than “t” I think that is clearer. If I were to do
it the other way XML2RFC would have double quotes in the text version.
John B.
On Jul 7, 2015, at 9:38 PM, William Denniss wdenn...@google.com wrote:
In
t_m works for me, I just think we should have some indication that it's
the name of the transform. Will you also update where it is referenced in
the description below Figure 2?
On Tue, Jul 7, 2015 at 6:28 PM, John Bradley ve7...@ve7jtb.com wrote:
Thanks, I fixed my finger dyslexia for the
Section 4.1.1 describes the parameters of the *authorization* request, not
the token request. After the user approves the scope in the authorization
request, the client exchanges the code for the access token. I'm talking
about the token request, where there is no scope parameter listed, section
23 matches
Mail list logo
