Hi John,
Sorry for a delay,
On 07/11/14 21:27, John Bradley wrote:
Inline.
On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:
Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:
Hi all,
I read through three of the OAuth proof-of-possession documents and
made
a few minor changes here and there (mostly editorial & updated
references).
Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
While there are a few open issues I believe that these three documents
are in fairly good shape.
Is someone willing to do a review?
Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:
- it is unclear what the new token_type if any is introduced, for
example, the section 6 says no new token type is introduced, while
the symmetric example uses a "pop" value and the assymetric key
response example says:
"The new token type "public_key" is placed into the 'token_type'
parameter"
Is the new type is actually introduced and it is "pop" and the
clients making the requests to RS should use a "POP"/"pop" scheme ?
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
uses "pop" but I'm not 100% sure...
The specs for the client accessing the RS need to define the token type.
There is likely to be more than one of those, signed message and TLS
channel binding.
I wonder, should it only be this PoP key distribution spec that would
use "pop", which is really about getting a regular token 'enhanced' with
a key. If I have AS returning a bearer token with a response containing
"token_type":"bearer", then when this AS receives a client token request
with a "token_type":"pop" it just means the bearer token to be returned
would have a key parameter bound to it.
Note IMHO it does not matter for the client whether the actual token
representation is JWT or an index, it is still a "token_type":"bearer"
as far as the client getting a token response is concerned.
So it won't lead to the proliferation of the new token types.
Something else that I wanted to suggest - can make no much sense but
here it goes:
Refresh tokens and indeed id_token OIDC tokens are just access token
response parameters but for them to be included in the response all what
is needed is for the client to include an extra scope in the redirection
request... Just a thought...
I am guessing that the channel binding one wouldn't support symmetric
proof keys.
Those specs may wind up profiling this spec to limit particular key
types etc.
The token_type in the request is saying give me a token to use over
this request method to the RS.
The AS might use the same logic to produce a AT for signed request and
TLS.
The other parameters are:
"aud" so that the AS can deal with multiple RS perhaps all with
different encryption keys and some using introspection.
"alg" indicating the alg of the proof key "HS256", "RS256", and
"ECDSA" being the current likely options.
(looking at that now I wonder if we also need to say anything about
key length/curve, I hope all of that can be sorted out in
registration so some sensible defaults would work for length/curve)
Those being important to any client RS protocol.
thanks for this extra info,
- The assymetric key example suggests that just a JWS-signed access
token is returned. This implies a client can easily introspect it -
which is not a big problem in this case - but it leads the client
toward writing a code that is bound to an access token structure -
therefore such a client code won't inter-operate with the AS sending
a bearer token; IMHO the access token structure should absolutely be
opaque to the clients, i.e, if it is JWT then it must be JWE protected
The intention is not to limit it to just JWS signed JWT, that should
be expanded if not clear.
SAML has the same problem with people sniffing tokens, so I agree that
the client should be precluded in the spec from doing that.
Forcing encryption of all the AT may be overkill and have negative
performance implications if not required for other reasons.
Nothing stops the AS and RS from using JWE encrypted JWT. Given that
in the symmetric key case between the AS and RS case a A128CBC-HS256
has AEAD Authenticated encryption so you don't need to sign the JWT
separately as an optimization. (I personally prefer A128CBC-HS256
over HS256 given that the performance hit is small, but that is just me.)
I'm afraid I'm not following that :-), but given that we do implement
"A128CBC-HS256 over HS256" now, I will afford asking, are you referring
here to the case of the PoP key being distributed in a plain form over
TLS vs being JWE-encrypted with "A128CBC-HS256 over HS256" ?
Requiring encryption is probably overkill.
I understand, as long as the client treats a JWS sequence as an opaque
blob, it is fine...
Thanks
Sergey
John B.
Thanks, Sergey
Ciao
Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
