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

[John Bradley <[e-mail]>]

I can easily see Research and education publishing self signed certs in meta-data that is then used for client authentication and other things.
I don’t want to limit this to only CA issued certs where the client_id is in the DN.    Client_id tend not to be domain names currently.
Looking up a raw key  provided via JWK in registration based on client_id will be one way that people will use this.   Passing the cert is seen as just a way of passing the key to many people.

I also understand the desire in ACE to save bytes.

If you are using self signed certs then including the client_id in the cert vs as a parameter is a bit of a no op re size.

Perhaps if there is a common pattern we could document a IoT profile where ca issued cert is used and what it would look like.

I have concerns that this may open a can of worms around what the CN would be and the interpretations of use extensions if this is flagged as something other than a host cert.    What do devices do now when they are issued certs.  Is there a common standard or is it by manufacturer.

My main concern would be to not hold up what should be a simple spec for the server to server case, but am willing to accommodate IoT if possible.

Regards
John B.

> On Oct 28, 2016, at 5:31 PM, Brian Campbell <[e-mail]> wrote:
> 
> Not wanting to add more meta parameters was a motivation. Also not being sure of how to enumerate the possible approaches. My thinking was also that there are a lot of factors involved and that it'd probably be better left to service documentation to describe things like what authorities are trusted and what the client to cert binding is. Like I said, we can look at adding more metadata, if there's some consensus to do so. But I worry that it'll just be bloat that doesn't really add value. 
> 
> I also think that, in many situations, it's unlikely that a cert will contain a client id anywhere as subject information. A client id is scoped to a particular authorization server and it's hard to imagine a CA issuing a cert with an identifier that's only meaningful in the context of some other entity like that. Maybe in a more closed system where the AS and an organizational CA are both in the same management/administrative domain but not in the more general case.   
> 
> 
> 
> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <[e-mail] <mailto:[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] <mailto:[e-mail]>
> >> wrote:
> >> Superb, I welcome that!
> >>
> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- <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] <mailto:[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] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>>, "John Bradley" <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[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 <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/ <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/>
> >> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 <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 [e-mail]://www.ietf.org/mailman/listinfo/oauth <http://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> 
> 
>