RE: [foaf-protocols] workplace certs (to be linked up with foaf+ssl)?

its best to just read the code, see https://github.com/AzureAD/azure-activedirectory-library-for-objc/blob/master/ADALiOS/ADALiOS/ADWorkplaceJoined.m
there is lots of apple/ios "technology" in there, for really professional grade TLS on Mac and IOS software coding, in those classes: key rings, protocol interceptors, certificate selectors etc.
if you want ,you can scan the OAUTH2 RFC/IDs for certificates, but the IETF spec is just a giant, PKI like, blob of verbose correctness now. it teaches nothing. yes, there are formalisms fr the case in question, that Do NOT tell the following story:-
Note that Im quite pro Microsoft (in the sense of its handling of the crypt politics); compared to Google (whose executive I view as just 100% complicit in the attempt at global and systemic crypto deception on the scale of CryptoAG). So Im biased. That said
In the Microsoft product model, client certs are part of the MDM world - where corporates control the devices, and provision such as trust stores, cipher suites, drivers generally, and cert-for-devices (to mark transactions as from-company-owned devices). One sees this built into any American retail smartphone, as the USB controllers boot from letting one flash the qualcomm chips firmware (insert spying firmware into the core soft radio logic and coding algorithms, before the phone ships), to then resetting the controller so it talks now to the chipset of the phone manufacturer motherboard (insert spying logic beneath the OS, in the "bios" essentially), to the re-resetting the controller so USB talks to windows/google OS, at which point cert trust stores are populated, drivers loaded, code signing trust points "altered" etc to suit the "app culture".
So recognize that client certs in TLS in the OAUTH world and from openid foundation vendors doesn't really have the same mission has folks claim to have here. But, it IS open source, so you can FORK!


From: henry.story@bblfish.net
Date: Wed, 30 Jul 2014 07:23:44 +0200
To: pwilliams@rapattoni.com
CC: public-webid@w3.org; foaf-protocols@lists.foaf-project.org
Subject: Re: [foaf-protocols] workplace certs (to be linked up with	foaf+ssl)?

Thanks for sharing. I do feel there has been a change of 
On 29 Jul 2014, at 22:25, Peter Williams <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
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architecthttp://bblfish.net/



_______________________________________________
foaf-protocols mailing list
foaf-protocols@lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols