Of *Brian
Campbell
*Sent:* Thursday, July 30, 2015 11:29 AM
*To:* Nat Sakimura sakim...@gmail.com
*Cc:* oauth oauth@ietf.org
*Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:
confirmation model in proof-of-possession-02)
Using individual claims for the different confirmation
Of *Brian Campbell
*Sent:* Thursday, July 30, 2015 11:29 AM
*To:* Nat Sakimura sakim...@gmail.com
*Cc:* oauth oauth@ietf.org
*Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:
confirmation model in proof-of-possession-02)
Using individual claims for the different confirmation
discussion that I'm aware of. Nat seemed in favor of
it (the +1 below). Mike was dismissive of it at the Dallas meeting but
didn't provide any reasoning (that I understood anyway).
On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura sakim...@gmail.com wrote:
+1
=nat via iPhone
2015/03/23 11:07、Brian
, Brian Campbell bcampb...@pingidentity.com
wrote:
When the JWT is itself encrypted as a JWE, would it not be reasonable to
have a symmetric key be represented in the cnf claim with the jwk member as
an unencrypted JSON Web Key?
Is such a possibility left as an exercise to the reader
My sense of the consensus in the room is as Justin describes it.
On Sat, Jul 25, 2015 at 9:14 AM, Justin Richer jric...@mit.edu wrote:
Consensus: For use of existing params defined in OAuth, while allowing
some to be optional when not needed.
That was not the consensus as I understood it in
the immediate value of amr_values, can you elaborate with
some places where this would be applied? Separately, I wonder if an
extension to OIDC should be included in this doc, which is otherwise a
fairly clean registry spec that could be used more broadly.
On Thu, Jul 23, 2015 at 10:49 AM, Brian
PCKE prevents a bad app from using the code when there's a collision in the
custom scheme used for the redirect URI. However the same app could
immediately issue a new authorization request with it's own PCKE parameters
and (mostly) transparently get back a code that it can use. Having some
user
So maybe a naive question but why does this draft define amr_values while
also suggesting that it's fragile and that acr acr_values is
preferable? Seems contradictory. And I doubt I'm the only one that will
find it confusing.
On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones
I think I said, at the last meeting, that I would review
draft-ietf-oauth-signed-http-request, which was maybe foolish of me, but I
thought I should be timely and send something before the meeting tomorrow.
Even though the document isn't on the agenda.
Let me first say that I honestly don't know
Any good access token implementation should make such scanning totally
infeasible (via sufficient entropy in the token, if it's a reference, or
cryptographic protections, if it's self contained).
Authentication/authorization at the introspection endpoint, in my view
anyway, is more about privacy
Though you want to be careful with that as the asymmetric algs in JWE don't
provide authentication of the sender.
On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura n-sakim...@nri.co.jp wrote:
Hi Malla,
Just to add one more thing:
If you just want to “sign” for the sake of integrity
the official draft during
the freeze before the IETF meeting.
https://bitbucket.org/Nat/oauth-spop
On Jul 9, 2015, at 3:19 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
I agree with William that it's a little confusing. I get that there's a
desire to discourage using plain but perhaps
I agree with William that it's a little confusing. I get that there's a
desire to discourage using plain but perhaps the language (especially the
MUST NOT in 7.2) should be lightened up just a bit?
On Wed, Jul 8, 2015 at 8:22 PM, William Denniss wdenn...@google.com wrote:
Following up the
,
-- Mike
*From:* Justin Richer [mailto:jric...@mit.edu]
*Sent:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Token Chaining Use Case
This approach is not a good fit for my use cases
Agree Sergey. That line of thinking is largely why
https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes normal OAuth
client authentication.
On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin sberyoz...@gmail.com
wrote:
On 08/07/15 01:41, Mike Jones wrote:
[...] That’s why the WG
:* Tuesday, July 07, 2015 4:47 PM
*To:* Mike Jones
*Cc:* Brian Campbell; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Token Chaining Use Case
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
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
but not 100% sure given
draft-richer-oauth-chain-00 covers a specific case.
One thing I'm not sure about is what is the purpose of specifying a
security_token_type of the returned access token
Thanks, Sergey
On 01/07/15 15:59, Brian Campbell wrote:
One problem, I think, with token exchange
the deployed services of WS-Trust
and Kerberos support in Windows (workstation and server) and Xbox.
*From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
Campbell
*Sent:* Monday, July 6, 2015 11:29 AM
*To:* Mike Jones michael.jo...@microsoft.com
*Cc:* oauth oauth@ietf.org
: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
Yes unfortunately we haven’t made any progress on this since accepting
Mike’s first draft.
His proposal
the Windows
Kerberos Protocol Transition/Constrained Delegation. The way you have the
text describes different set use case then what the feature of
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
describes.
*From:* Brian Campbell [mailto:bcampb...@pingidentity.com
One problem, I think, with token exchange is that it can be really simple
(token in and token out) and really complicated (client X wants a token
that says user A is doing something on behalf of user B) at the same time.
I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an
This document https://goo.gl/6uWxT7[0] was something done during the
course of some work a few months ago - it briefly proposes how a JWK Key ID
can be used within an XML Signature to convey to the recipient what key was
used to sign the XML and thusly what key to use to verify the signature. It's
IMHO use is less useful for JWKs of type oct but not to the point of
disallowing it.
Your question is probably better suited for the JOSE WG list though, rather
than OAUTH.
On Sun, Apr 19, 2015 at 4:01 AM, Vladimir Dzhuvinov vladi...@connect2id.com
wrote:
A developer working with the Nimbus
I'm hardly speaking with any authority here but my hope/expectation is that
using Origin Only for the Referrer Policy would provide enough info in the
referer (the origin) so as to not break search engines flows or other
analytics that are using data from the referer header. The referring domain
This kind of token exchange might involve exchanges other than swapping an
AT for another AT (and downscoping it). It might be an AT for a structured
JWT specifically targeted at one of the the particular services that the
original RS needs to call. Or an AT might be exchanged for a SAML assertion
. It’s the RS
that confirms the claim (in OAuth PoP), or whoever’s processing the
key-protected call downstream (in something that isn’t OAuth).
— Justin
On Mar 25, 2015, at 9:37 AM, Brian Campbell bcampb...@pingidentity.com
wrote:
There's similar wording in sec 3.3
https://tools.ietf.org
OK for particular applications to
require that it be single-valued in their usage.
-- Mike
*From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
Campbell
*Sent:* Wednesday, March 25, 2015 2:08 PM
*To:* oauth
Here are the slides that I rushed though at the end of the Dallas meeting:
https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf
And the -00 draft:
http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00
In an informal discussion earlier this week John B. suggested that some
from my Windows Phone
--
From: Brian Campbell bcampb...@pingidentity.com
Sent: 3/25/2015 2:19 PM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Destination Claim
FWIW, I did have that as an open issue in the draft
And here's the somewhat different take on token exchange that I mentioned
yesterday:
https://tools.ietf.org/html/draft-campbell-oauth-sts-01
A little more background, context, and discussion about it can be seen
following the thread on the Call for Adoption of OAuth 2.0 Token Exchange
as an OAuth
+1
The JWT may well be about the sub but presented by some software component
that should be independently identified.
On Mon, Mar 23, 2015 at 2:25 AM, Nat Sakimura sakim...@gmail.com wrote:
Re:
https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3
I understand the
Do folks in the WG think there'd be utility in having a way to identity the
finger/thumbprint of a key in the cnf claim. A presenter might, for
example, present the JWT along with a public JWK and some
proof-of-possession of that JWK. And the JWK would be bound to the JWT via
the thumbprint,
When the JWT is itself encrypted as a JWE, would it not be reasonable to
have a symmetric key be represented in the cnf claim with the jwk member as
an unencrypted JSON Web Key?
Is such a possibility left as an exercise to the reader? Or should it be
more explicitly allowed or disallowed?
Brian Campbell bcampb...@pingidentity.com:
I wasn't necessarily suggesting to drop the kid one.
On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura sakim...@gmail.com wrote:
+1 for dropping kid in favor of thumbprint.
2015年3月23日(月) 12:56 Brian Campbell bcampb...@pingidentity.com:
Yeah, it could
Looks like we are heading to the bbq grill at the hotel, if you're (Hannes)
late and still want to join us.
On Mar 22, 2015 6:10 PM, Derek Atkins de...@ihtfp.com wrote:
Hi,
Hannes and I would like to have a lunch meeting before the OAUTH meeting
to chat about various ongoing WG activities.
, Mar 23, 2015 at 2:11 AM, Nat Sakimura sakim...@gmail.com wrote:
Would not kid do?
Right, thumbprint has more semantics and has nice properties, but having
too many ways is not good for interop.
Nat
2015-03-23 15:40 GMT+09:00 Brian Campbell bcampb...@pingidentity.com:
Do folks in the WG
I wasn't necessarily suggesting to drop the kid one.
On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura sakim...@gmail.com wrote:
+1 for dropping kid in favor of thumbprint.
2015年3月23日(月) 12:56 Brian Campbell bcampb...@pingidentity.com:
Yeah, it could be done with kid. But that would require
It says, The asymmetric key mechanism described above is conceptually
similar to a certificate. near the end of
https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-1
That kinda jumped out at me. I mean, I kinda see the point but it also
seems like a pretty broad statement
At the end of section 3
https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3
it says, 'At least one of the sub and iss claims MUST be present in the
JWT, and in some use cases, both MUST be present.'
Admittedly I've misused RFC 2119 keywords a few times myself, so I say
Hannes
On 02/18/2015 05:45 PM, Brian Campbell wrote:
There's a bit of MTI talk tucked into
https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
perhaps needs to be expanded and/or placed somewhere else.
On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
hannes.tschofe
On Wed, Feb 18, 2015 at 7:38 AM, John Bradley ve7...@ve7jtb.com wrote:
I don’t remember precisely , but I may be the one responsible for the for
the 2^(-128) value for code.
The archives have a more precise memory
http://www.ietf.org/mail-archive/web/oauth/current/msg03844.html ;)
I tend to agree with Torsten here - similar sentiments were (maybe not
well) expressed a few weeks ago:
http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html
On Wed, Feb 18, 2015 at 6:36 AM, tors...@lodderstedt.net wrote:
Hi Nat,
as far as I understand, the length of at least 32
To clarify what I said there: 22-chars (128 bits) seems like way more than
enough for a lower limit when using the plain challenge method. When
using the S256 challenge method, exactly 43 char (256 bits) should
probably always be used.
On Thu, Feb 5, 2015 at 11:09 AM, Brian Campbell bcampb
22-chars (128 bits) as a lower limit seems just fine for this case.
ccm works for me but I don't feel strongly about it either way.
On Thu, Feb 5, 2015 at 9:49 AM, John Bradley ve7...@ve7jtb.com wrote:
Inline
On Feb 4, 2015, at 10:43 PM, Manger, James
james.h.man...@team.telstra.com
I went thought appendix B and reproduced the same calculations. Which is
nice.
One little nit - to be consitent with the notation defined in §2, the appendix
B should have
BASE64URL(SHA256(ASCII(code_verifier))) == code_challenge
rather than
Base64url(SHA256(ASCII(code_verifier ))) ==
:
code_verifier = high entropy cryptographic random
octet sequence using the url and filename safe Alphabet [A-Z] / [a-z]
/ [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length
less than 128 characters.
Nat
2015-01-30 22:51 GMT+09:00 Brian Campbell bcampb
https://bitbucket.org/Nat/oauth-spop/commits/af9ce76988cd32b334e21c71289721a3bf1c4ff1
looks good to me. Thanks John.
On Fri, Jan 30, 2015 at 1:47 PM, John Bradley ve7...@ve7jtb.com wrote:
OK try that one.
On Jan 30, 2015, at 5:15 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
I agree
.
SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234]
http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC6234 of OCTETS.
On Jan 30, 2015, at 08:15, Brian Campbell bcampb...@pingidentity.com
wrote:
In §2 [1] we've got SHA256(STRING) denotes a SHA2 256bit hash [RFC6234]
of STRING
In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization
request going to the Resource Owner and goes on to say that 'the resource
owner responds as usual, but records t(code_verifier) and the
transformation method.' That's not what the resource owner does.
I know the protocol flow
-| |
++ +---
On Jan 29, 2015, at 7:01 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization
request going to the Resource Owner and goes on to say that 'the resource
in the Access Token Request as
usual, but includes the code_verifier secret generated at (A).
D. The authorization server transforms code_verifier and compares
it to t(code_verifier) from (B). Access is denied if they are
not equal.
On Jan 29, 2015, at 7:16 PM, Brian Campbell
My question was not really about the status of
draft-bradley-oauth-stateless-client-id but rather about
draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless
client id that Bradley described in his draft.
And draft-ietf-oauth-dyn-reg-management still has text that says, 'The
Given the state of things, maybe the MAC Token specification
[I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted?
On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills wmills_92...@yahoo.com wrote:
There's a draft it would be great to get more eyes on in the Kitten WG
In the into, I'd suggest changing,
The code verifier is created for every authorization request...
to
A unique code verifier is created for every authorization request...
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I struggle to see the value in adding more fine grained machine readable
error messages for this.
Do we really want clients to try and negotiate the code_challenge_method
using browser redirects? Especially in light of the fact that we'll likely
also be discouraging AS's from redirecting on some
structured client_id values.
But as this is now tagged as experimental, we could also just publish it
as is and see if anybody actually tried to deploy those two options
together.
-- Justin
/ Sent from my phone /
Original message
From: Brian Campbell bcampb
I agree that changing the name could avoid a lot of unnecessary confusion
(and said as much in Sept
https://www.ietf.org/mail-archive/web/oauth/current/msg13361.html).
On Wed, Nov 12, 2014 at 9:46 AM, Bill Mills wmills_92...@yahoo.com wrote:
Any progress on naming on this thing? Didn't see
Forwarding this to the WG.
There is a word missing in the sentence noted below as well as in the
similar sentence in the SAML draft. However, I believe it should be to the
client rather than about the client.
What is the most appropriate way to handle a minor fix like this at this
stage? A note
update, that would be easier to prevent it
from getting lost. The shepherd and I will recheck the draft and then
I'll move it forward.
Thanks for all of your work on this!
Kathleen
On Wed, Nov 12, 2014 at 12:05 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
Forwarding this to the WG
New versions of all three OAuth assertion documents (listed below) have
been published with changes incorporating feedback received during IESG
Evaluation.
Assertion Framework for OAuth 2.0 Client Authentication and Authorization
Grants
I received the below over the weekend and, although oauth@ietf.org is cc'd,
it didn't post to the list - I assume because sampo-i...@zxidp.org isn't
subscribed. I thought I should send to the WG list so folks are aware.
I don't believe EncryptedAssertion should be supported, for three main
In the default case, aren't the challenge and verifier just an arbitrary
string value? One that would be application/x-www-form-urlencoded on the
authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1)
and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like
any
and code_challenge would
be expressed in unreserved.
Nat
2014-10-20 15:13 GMT-05:00 Brian Campbell bcampb...@pingidentity.com:
In the default case, aren't the challenge and verifier just an arbitrary
string value? One that would be application/x-www-form-urlencoded on the
authorization request (http
party uses an assertion that was not intended for it, it cannot
obviously hold the asserting party responsible.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Oct 16, 2014, at 8:43 AM, Brian Campbell bcampb...@pingidentity.com
wrote:
Thanks for your review
On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes r...@ipv.sx 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 Barnes
Touché... ;)
On Thu, Oct 16, 2014 at 4:36 PM, Richard Barnes r...@ipv.sx 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
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
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
otherwise) I'm
not sure what to say or where based on your suggestion below. Is there
something specific you can suggest (and where to put it)?
Thanks,
Brian
On Thu, Oct 16, 2014 at 3:20 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell
Thanks for your review and feedback on this one too, Pete. Replies are
inline below...
On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick presn...@qti.qualcomm.com
wrote:
Pete Resnick has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: No Objection
When responding,
Likewise, I will not repeat stuff here but will apply appropriate changes
from your comments on draft-ietf-oauth-saml2-bearer as they apply here to
draft-ietf-oauth-jwt-bearer.
On Tue, Oct 14, 2014 at 8:05 PM, Pete Resnick presn...@qti.qualcomm.com
wrote:
Pete Resnick has entered the following
A JWT, by it's very definition, is a set of base64url pieces concatenated
together with dot . characters (which is also URL safe). So no additional
encoding or serialization of the JWT is needed.
On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
Stephen Farrell
in this
morning.
-- Forwarded message --
From: Brian Campbell bcampb...@pingidentity.com
Date: Thu, Oct 16, 2014 at 8:34 AM
Subject: Re: [OAUTH-WG] Ted Lemon's Discuss on
draft-ietf-oauth-assertions-17: (with DISCUSS)
To: Ted Lemon ted.le...@nominum.com
On Thu, Oct 16, 2014 at 7:42 AM, Ted
Thanks for your review and feedback, Richard. Replies are inline below...
On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes r...@ipv.sx wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss
When responding, please keep the subject line
Thanks for your review and feedback, Stephen. Replies are inline below...
On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: No Objection
When responding, please
Thanks for your review and feedback on this one too, Stephen. Replies are
inline below...
On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss
When responding,
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 Barnes r...@ipv.sx wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-oauth-jwt-bearer-10: Discuss
When responding, please keep the
Basically the same response to the basically same question as from
http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html
On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes r...@ipv.sx wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21:
On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
Some stuff needs to be exchanged out-of-band for this to work.
Entity/issuer/audience identifiers are part of that. This need is
discussed
in the Interoperability Considerations at
Hiya in return and inline below...
On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
JOSE one has only H256 as required.
Doesn't that seem like one is unacceptably old and the other
is not
kathleen.moriarty.i...@gmail.com wrote:
On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
Hiya in return and inline below...
On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
Hmm. So the SAML one only seems to have RSA-SHA1
Thanks for your review and feedback, Vincent. I'm adding the working group
to the thread so they’re aware of the comments. Replies are inline below...
From: Vincent Roca vincent.r...@inria.fr
Date: Tue, Oct 14, 2014 at 9:10 AM
Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21
To:
Thanks for your review and feedback, Pete. Replies are inline below...
On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick presn...@qti.qualcomm.com
wrote:
Pete Resnick has entered the following ballot position for
draft-ietf-oauth-assertions-17: No Objection
When responding, please keep the
Fair point. I'll add some text saying that in the next revision.
On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba barryle...@computer.org
wrote:
Assertions used in the protocol exchanges defined by this
specification MUST always be protected against tampering using a
digital signature
Repeating the note about acceptable algorithms in the JWT spec sounds fine.
On Sat, Oct 11, 2014 at 1:54 PM, Mike Jones michael.jo...@microsoft.com
wrote:
From: Richard Barnes [mailto:r...@ipv.sx]
Sent: Friday, October 10, 2014 2:37 PM
To: Mike Jones
Cc: The IESG;
.
-- Justin
* And I just noticed that this paragraph still mentions the delete
action, so we need to clean that part up in the next revision.
On Sep 11, 2014, at 6:19 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
Why does expiration only apply to the client secret[1]? If there's
Why does expiration only apply to the client secret[1]? If there's a need
for the AS to set an expiration, isn't it broader than that and apply to
the whole client or the client id? If there's a need to signal an
expiration time on the client secret, doesn't it follow that the client's
JSON Web
cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
I agree that plaintext” is not the most intuitive wording choice and that
unsecured might better convey what's going on with the none JWS
algorithm.
Mike mentioned that, if this change is made in JWT, there are parallel
changes
On #1, I know some have pushed for having the transformation options so I
don't know if dropping it will work. But, if not removed entirely, the
transformation stuff could definitely be deemphasized in favor of what will
be the most common case of the client sending a random string value on the
I'd be okay with that as a way forward. Frankly, of course, I'd prefer to
see draft-campbell-oauth-sts as the starting point with Mike and the other
draft-jones-oauth-token-exchange authors added as co-authors. Regardless,
there are elements from both that likely need to end up in the final work
Yes (sorry I'm a little late with this one)
On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Hi all,
during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the Request by JWS ver.1.0 for OAuth 2.0
these
comments along to the list in your response to this Call for Adoption.
Ciao
Hannes Derek
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
[image: Ping Identity logo] https://www.pingidentity.com/
Brian
Absolutely agree that some examples are needed. There's a [[ TODO ]] in
there for it. I just hadn't gotten to it yet and wanted to get the I-D up
before the Aug 10 date that Hannes put out there. The example you outlined
is a good start, I think.
Yes, code and refresh tokens would/could be valid
Take a look at RFC 6750 The OAuth 2.0 Authorization Framework: Bearer
Token Usage - particularly section 3:
http://tools.ietf.org/html/rfc6750#section-3 which describes using the
WWW-Authenticate response header field in response to a request with
an invalid/insufficient/missing/etc token.
On
Will the minutes of the meeting be made available? Those might provide
a little more context to those of us who were unable to attend.
On Wed, Jul 30, 2014 at 10:14 AM, John Bradley ve7...@ve7jtb.com wrote:
Interesting point. I defer to your greater hum experience:)
On Jul 30, 2014, at 10:32
I'd note that the reaction at the conference to Ian's statement was
overwhelmingly positive. There was a wide range of industry people here -
implementers, practitioners, deployers, strategists, etc. - and it seems
pretty clear that the rough consensus of the industry at large is that
a4c is not
or
understand the usage.
*From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
Campbell
*Sent:* Thursday, July 24, 2014 6:53 AM
*To:* Nat Sakimura
*Cc:* oauth@ietf.org list
*Subject:* Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-v2-user-a4c-05.txt
I'd note
endpoint. in combination with 1, 2, or 3
I agree that stoping developers doing insecure things needs to be
addressed somehow.
I am not personally convinced that Oauth without access tokens is sensible.
Looking forward to the meeting:)
John B.
On Jul 24, 2014, at 6:52 AM, Brian Campbell
doing insecure things needs to be
addressed somehow.
I am not personally convinced that Oauth without access tokens is sensible.
Looking forward to the meeting:)
John B.
On Jul 24, 2014, at 6:52 AM, Brian Campbell bcampb...@pingidentity.com
wrote:
I'd note that the reaction
801 - 900 of 1167 matches
Mail list logo
