- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 30 Jul 2014 07:53:11 +0200
- To: Web Payments CG <public-webpayments@w3.org>
Very strange. Never heard about it before. -------- Original Message -------- Subject: Re: [foaf-protocols] workplace certs (to be linked up with foaf+ssl)? Resent-Date: Wed, 30 Jul 2014 05:24:18 +0000 Resent-From: public-webid@w3.org Date: Wed, 30 Jul 2014 07:23:44 +0200 From: henry.story@bblfish.net <henry.story@bblfish.net> To: Peter Williams <pwilliams@rapattoni.com> CC: foaf-protocols@lists.foaf-project.org <foaf-protocols@lists.foaf-project.org>, WebID <public-webid@w3.org> Thanks for sharing. I do feel there has been a change of On 29 Jul 2014, at 22:25, Peter Williams <pwilliams@rapattoni.com <mailto:pwilliams@rapattoni.com>> wrote: > Interestingly, the US government (and aligned EU) national security vendor community, acting through IETF, have arranged that TLS client certs, known as workplace (or device) certs in Microsoft land, can now be supplied during an OAUTH handshake. > > This means that rather than show a browser page asking for uid/password etc, the browser page auto-presents the client cert. In response, the authorization code is returned by the server (which figures that it doesn’t need to offer any user prompt). Do you have a reference to the point in a spec for this? > > In MIcrosoft’s authentication library for objective-C (i.e. MacOS and IOS) one sees the client side of this process, tied to URL protocol schemes, with the iphone searching its tls client keystores for suitable certs when the https scheme (or other) is detected. A pointer would be useful. > Is there not a obvious hookup potential here, assuming folks here at not already part of that community, between webid, tls certs, and such authorization endpoints .. that now actively soliciting client certs (for the first time in 20+ years…) yes, clearly, they would not need to only look for the certificates only one certain networks but would be able to look anywhere on the web. > > Strikes me that a webid validation process (ping back on the foaf card/chain), at the authorization servers endpoint, could be augmenting the process of deciding if the webid is good…enough, to return the JSON response bearing the authorization code. > > Its also worth pointing out a sea change in attitude, at least in microsoft identity land (which means US govt land). Now, its apparently ALLOK for a server to make a call out to trust documents, when validating inbound crypto credentials (like client certs). Thus one CAN now call out to go get foaf docs (or other metadata, such as ws-fed metadata); whereas it was verboten only a year or two ago (creating endless mayahem for server farms…) > > Reminds me a little of 1992-era science, when you’d hear senior academics “in the know” say how a DES bruteforcing engine would create more heat than could be eliminated(until someone did it, and proved that it was all propaganda). Great. Things can change. > > > > Sent from Surface Pro > > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org <mailto:foaf-protocols@lists.foaf-project.org> > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols Social Web Architect http://bblfish.net/
Received on Wednesday, 30 July 2014 05:53:56 UTC