Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Samuel Erdtman <[e-mail]>]

I think it is awesome that this document has been written since this is one
of the solutions that exists in the wild.

However I think that the connection to client (client_id) and certificate
could be more clearly specified, at the moment it is exemplified under
security considerations. I think there should be text saying that there
MUST be a binding and provide the default solution e.g. client_id as
subject common name.

Further I would prefer if it was not a MUST to include the client_id in the
HTTP request since I think there MUST exist a client binding in the
certificate. I think there is no need to have it explicitly in the HTTP
request. This might not be a problem for Classic OAuth but when adopted for
ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
we would like to lessen the duplicated information as much as possible.

//Samuel


On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <[e-mail]
> wrote:

> I see. Do you reckon the AS could simply probe the likely cert places
> for containing the client_id? My reasoning is that there aren't that
> many places where you could stick the client_id (let me know if I'm
> wrong). If the AS is in doubt it will respond with invalid_client. I'm
> starting to think this can work quite well. No extra meta param will be
> needed (of which we have enough already).
>
> On 22/10/16 01:51, Brian Campbell wrote:
> > I did consider something like that but stopped short of putting it in the
> > -00 document. I'm not convinced that some metadata around it would really
> > contribute to interop one way or the other. I also wanted to get the
> basic
> > concept written down before going too far into the weeds. But I'd be open
> > to adding something along those lines in future revisions, if there's
> some
> > consensus that it'd be useful.
> >
> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <
> [e-mail]
> >> wrote:
> >> Superb, I welcome that!
> >>
> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
> >> client-auth-00#section-5.2 :
> >>
> >> My concern is that the choice of how to bind the client identity is left
> >> to implementers, and that may eventually become an interop problem.
> >> Have you considered some kind of an open ended enumeration of the
> possible
> >> binding methods, and giving them some identifiers or names, so that AS /
> >> OPs can advertise them in their metadata, and clients register
> accordingly?
> >>
> >> For example:
> >>
> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
> >> "subject_public_key_info_match" ]
> >>
> >>
> >> Cheers,
> >>
> >> Vladimir
> >>
> >> On 10/10/16 23:59, John Bradley wrote:
> >>
> >> 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: [e-mail]
> >> 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" <[e-mail]> <
> [e-mail]>, "John Bradley" <[e-mail]> <
> [e-mail]>
> >>
> >>
> >> 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.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/
> oauth
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>