Phil, what is your +1 referring to? //Samuel
On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > +1 > > Phil > > On Nov 4, 2016, at 6:11 PM, John Bradley <ve7...@ve7jtb.com> 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 <bcampb...@pingidentity.com> > 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 < > vladi...@connect2id.com> 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 < >> vladi...@connect2id.com >> >> 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: internet-dra...@ietf.org >> >> 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" <brian.d.campb...@gmail.com> < >> brian.d.campb...@gmail.com>, "John Bradley" <ve7...@ve7jtb.com> < >> 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/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 listOAuth@ietf.orghttps://www. >> ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
