Whoops, "about" at the end of the 1st paragraph should be "abort".
On Nov 16, 2016 8:08 AM, "Brian Campbell"
wrote:
> Yes, I believe you are correct. Client certificates are provided in the
> handshake (initial or renegotiated) at the request of the server. If the
> server asks and the client do
In this document the information is very much intended for the
authorization server so that it can make appropriate policy choices about
the token to be issued.
On Tue, Nov 15, 2016 at 4:50 AM, Denis wrote:
> Hello everybody,
>
> Since I am not present at the meeting, I read the minutes from the
Yes, I believe you are correct. Client certificates are provided in the
handshake (initial or renegotiated) at the request of the server. If the
server asks and the client doesn't provide a cert, it's up to the server
whether to continue or about the handshake.
There seem to be a number of differe
Torstens questions triggers another question from me.
If we have an AS that can handle both certificate client auth and client
secret, how does the AS know that it should ask for client certificate on
the TLS layer.
It was a while since I last read the TLS specification and it might have
changed
The reason I think it is a workaround to use the jwks or jwks_uri is that
you would then wrap the x5u, x5c and/or x5t in a jwk object that you do not
really need. So the implementation needs to be aware of how to create and
read jwk even though it will not use any of the jwk data.
With that said,
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
session, in particular:
Brian Campbell and John did a draft allowing the client to tell the
AS where it plans to use the token
draft-campbell-oauth-resource-indicators
This ena
