Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Thanks! From: Richard Barnes Sent: ‎11/‎11/‎2014 3:30 PM To: Mike Jones Cc: Brian Campbell; John Bradley; draft-ietf-oauth-asserti...@tools.ietf.or

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Looks good to me, thanks. I cleared. --Richard On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones wrote: > Richard, yours are the only discusses on draft-ietf-oauth-assertions, > draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re > all about the audience requirement. Brian ad

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Yeah I think that's fair (though regrettable:-). Will look at it before the meeting. S On 12/11/14 00:03, Mike Jones wrote: > Hi Stephen, > > Your DISCUSS on "alg":"none" being MTI is the only one remaining on the JWT > draft. Given the working group support for keeping things the way they ar

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Richard, yours are the only discusses on draft-ietf-oauth-assertions, draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re all about the audience requirement. Brian added text addressing this in the last paragraph of https://tools.ietf.org/html/draft-ietf-oauth-assertions

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Hi Stephen, Your DISCUSS on "alg":"none" being MTI is the only one remaining on the JWT draft. Given the working group support for keeping things the way they are, would you be willing to clear this DISCUSS on that basis? The OAuth WG meeting is tomorrow, so it would be good to hear your thou

Re: [OAUTH-WG] Updated OAuth PoP documents

Hi John Sorry for being noisy. I'd like to clarify. I was not thinking of the application getting a JWS, I was rather thinking of doing something similar to GZIP really, where on the wire we see a gzipped payload but the application gets the data it understands. One filter would validate the '

Re: [OAUTH-WG] Updated OAuth PoP documents

On 11/11/14 17:22, Justin Richer wrote: What you’re talking about is changing the body of your API to be a JWS directly, and that’s fine if your API wants to do things that way. Just define it as part of what your API expects — there are several out there that can do this. But that’s not what

Re: [OAUTH-WG] Updated OAuth PoP documents

Personally I think that sending a JWS as the body is a fine idea, though I would not directly tie that to POP because that are likely validated at different levels. OAuth should not be in the business of extracting body content from the JWS. If the RS wants to pass the key for validating the J

Re: [OAUTH-WG] Updated OAuth PoP documents

What you’re talking about is changing the body of your API to be a JWS directly, and that’s fine if your API wants to do things that way. Just define it as part of what your API expects — there are several out there that can do this. But that’s not what this work is about. This work is very expl

Re: [OAUTH-WG] Updated OAuth PoP documents

The token type is about the client RS binding. It is up to the specs like http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0 to register the token types. It may be possable for more than one binding to use the same token type, but that is up to them. The term "token type" i

Re: [OAUTH-WG] Updated OAuth PoP documents

Hi Justin I'm sorry, I've missed it What is your opinion of having a body optionally wrapped into JWS and JWS being sent as a body, as an alternative (while keeping 'b' as an option too). It can allow for streaming, as opposed to calculating the body hash in memory...JWS can be calculated dyn

Re: [OAUTH-WG] Updated OAuth PoP documents

It already does offer a body hash, optional like the rest of the parameters https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3 (see the “b” parameter) — Justin On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin wrote: > On 10/11/14 16:56, John Bradley wrote: >> For sen

Re: [OAUTH-WG] Updated OAuth PoP documents

On 10/11/14 16:56, John Bradley wrote: For sending JWE symmetric key to the client the Key Encryption Key is client public key provisioned out of band or pushed to the AS in the request. (The same applies to key agreement) Thanks... I suggested earlier to consider using 'bearer' token type