Comments in-line:
> On 14 Mar 2019, at 18:50, Brian Campbell wrote:
>
> Certificate-binding refresh tokens issued to *public clients* (those that
> don't have authentication credentials established with the AS, a.k.a. clients
> configured or registered with the "none" authentication method, wh
The one use case I've run across for introspecting refresh_tokens is to
determine the lifetime of the refresh_token (i.e. when it expires). Some
authorization servers bind the refresh_token to the user's
authentication session and hence they have a defined lifetime. I suppose
another use case m
Certificate-binding refresh tokens issued to *public clients* (those that
don't have authentication credentials established with the AS, a.k.a.
clients configured or registered with the "none" authentication method,
which will typically be native apps on a phone or similar) adds protections
against
Yeah Filip, that's about right. Currently the text says to do it only for
public clients (clients using "none").
On Thu, Mar 14, 2019 at 6:53 AM Filip Skokan wrote:
> Thank you for the clarification Brian, this makes sense.
>
> So for clients not using mtls (or is this only clients using "none"?
It’s not clear to me how this works or what problem it is solving. If a refresh
token is bound to the certificate, does that mean that a call to the
introspection endpoint with that refresh token should also return a “cnf” claim
as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section
There are icon links for audio and video next to the sessions on the agenda
at https://datatracker.ietf.org/meeting/104/agenda/. I believe registration
is required (but is free for remote participants). See
https://www.ietf.org/how/meetings/104/remote/ for more official
information.
Recordings wil
Thank you for the clarification Brian, this makes sense.
So for clients not using mtls (or is this only clients using "none"?) to
authenticate the tls_client_certificate_bound_access_tokens client metadata
property also conditions binding the refresh token. At the cost of the RT
being unusable if
Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound
to the client to whom it was issued. And that confidential clients (those
having established authn credentials) authenticate to the AS when
presenting a refresh token. Thus, for both MTLS methods of OAuth client
authenticati
Right - this is what we have implemented. No support for certificate-bound
refresh tokens, the client can be configured to require TLS cert client
authentication instead.
Neil
> On 14 Mar 2019, at 08:09, Filip Skokan wrote:
>
> Point being that since the refresh token is only usable on the I
Hi,
Are these sessions recorded / available to follow online?
Regards,
--larsw
From: OAuth On Behalf Of Rifaat Shekh-Yusef
Sent: onsdag 13. mars 2019 18:46
To: oauth
Subject: Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings
Use the following links instead:
https://datatracker.ietf.
Point being that since the refresh token is only usable on the IdP then
mtls client auth already covers this, and since RTs are long-lasting, it
does this better because cert rotation is possible for both mtls methods.
S pozdravem,
*Filip Skokan*
On Thu, 14 Mar 2019 at 08:07, Filip Skokan wrote
Even before refresh tokens were mentioned in draft 13 i was about to
implement this binding in nodejs oidc-provider,
the thing i struggled with and ultimately didn't do this was
1) if the refresh token is bound to a specific cert then this cert rotation
is out of the question
2) if having the RT
12 matches
Mail list logo
