I understand. My point is different: the text seems to assume everybody
is using client registration, but that's not the case. I would like to
point out it makes sense to explicitely state the assumption that it is
determined by client policy (indepedent of the way this policy is
established).
Am 13.11.2016 um 14:24 schrieb Justin Richer:
As part of the client’s registered data model. At least, based on how
our own implementation works (where we support client_secret_basic,
private_key_jwt, etc), that’s where we’d check to see if the client
was supposed to be using TLS auth or not.
We don’t let clients switch away from their registered auth mechanism.
— Justin
On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Justin,
Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the
tls_client_auth value specified in §3.
in the token request?
Nit on that section, the field name for the client metadata in
RFC7591 is token_endpoint_auth_method, the _supported version is
from the corresponding discovery document.
— Justin
Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Hi John and Brian,
thanks for writting this draft.
One question: how does the AS determine the authentication method
is TLS authentication? I think you assume this is defined by the
client-specific policy, independent of whether the client is
registered automatically or manually. Would you mind to explicitely
state this in the draft?
best regards,
Torsten.
Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API
Working group, Brian Campbell and I have documented
mutual TLS client authentication. This is something that lots of
people do in practice though we have never had a spec for it.
The Banks want to use it for some server to server API use cases
being driven by new open banking regulation.
The largest thing in the draft is the IANA registration of
“tls_client_auth” Token Endpoint authentication method for use in
Registration and discovery.
The trust model is intentionally left open so that you could use a
“common name” and a restricted list of CA or a direct lookup of
the subject public key against a reregistered value, or something
in between.
I hope that this is non controversial and the WG can adopt it quickly.
Regards
John B.
Begin forwarded message:
*From: *internet-dra...@ietf.org
*Subject: **New Version Notification for
draft-campbell-oauth-tls-client-auth-00.txt*
*Date: *October 10, 2016 at 5:44:39 PM GMT-3
*To: *"Brian Campbell" <brian.d.campb...@gmail.com>, "John
Bradley" <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>
A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.
Name:draft-campbell-oauth-tls-client-auth
Revision:00
Title:Mutual X.509 Transport Layer Security (TLS) Authentication
for OAuth Clients
Document date:2016-10-10
Group:Individual Submission
Pages:5
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status:
https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized:
https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
Abstract:
This document describes X.509 certificates as OAuth client
credentials using Transport Layer Security (TLS) mutual
authentication as a mechanism for client authentication to the
authorization server's token endpoint.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org/>.
The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
