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

[Samuel Erdtman <[e-mail]>]

Phil, what is your +1 referring to?

//Samuel

On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) <[e-mail]>
wrote:

> +1
>
> Phil
>
> On Nov 4, 2016, at 6:11 PM, John Bradley <[e-mail]> wrote:
>
> 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]> 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-clien
>> t-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/d
>> raft-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
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>