Removed references to TLS as primary auth method

Author: jaxoncreed

README.md

@@ -14,9 +14,6 @@
     * [WebID Profile Documents](#webid-profile-documents)
 4. [Authentication](#authentication)
     * [Primary Authentication](#primary-authentication)
-      * [WebID-TLS](#webid-tls)
-      * [Alternative Authentication
-          Mechanisms](#alternative-authentication-mechanisms)
     * [Secondary Authentication: Account
         Recovery](#secondary-authentication-account-recovery)
 5. [Authorization and Access Control](#authorization-and-access-control)
@@ -106,7 +103,7 @@ services also have a *secondary authentication mechanism* (usually an external
 email address) that they use for account recovery (in case the user forgets or
 loses their primary authentication tokens, username and password).
 
-Solid currently uses WebID-TLS as its primary authentication mechanism.
+Solid currently uses WebID-OIDC as its primary authentication mechanism.
 Alternative complementary mechanisms are also being actively investigated.
 In addition, Solid recommends that server implementations also offer secondary
 authentication available for users for Account Recovery (via email or some
@@ -120,44 +117,14 @@ platforms and ecosystems. Specifically, it requires *cross-domain*,
 de-centralized authentication mechanisms not tied to any particular identity
 provider or certificate authority.
 
-#### WebID-TLS
-
-**Note:** Several browser vendors (Chrome, Firefox) have removed support
-for the `KEYGEN` element, on which WebID-TLS relied for in-browser certificate
-generation.
-
-Solid uses the [WebID-TLS
-protocol](http://www.w3.org/2005/Incubator/webid/spec/tls/) as one of its
-primary authentication mechanism. Instead of usernames, it uses WebIDs as unique
-identifiers, as previously mentioned. And instead of using passwords as bearer
-tokens, it uses cryptographic certificates (stored and managed by the user's web
-browser) to prove a user's identity.
-
-When accessing a Solid server using WebID-TLS, a user is presented by their
-web browsers with a popup asking them to select an appropriate security
-certificate for that site. After a user makes their selection, the server
-securely matches the private key stored by the browser with the public key
-stored in that user's [WebID Profile Document](#webid-profile-documents), and
-authenticates them.
-
-**See component spec:
-  [Solid WebID-TLS Specification](authn-webid-tls.md)**
-
 #### WebID-OIDC
 
-The Solid team is currently implementing support for WebID-OIDC as another
-primary authentication mechanism. It is based on the OAuth2/OpenID Connect
+WebID-OIDC is based on the OAuth2/OpenID Connect
 protocols, adapted for WebID based decentralized use cases.
 
 **See component spec:
   [WebID-OIDC Specification](https://github.com/solid/webid-oidc-spec)**
 
-#### Alternative Authentication Mechanisms
-
-There are several other authentication mechanisms that are
-currently being investigated, such as combinations of traditional
-username-and-password authentication and WebID-TLS Delegation).
-
 ### Secondary Authentication: Account Recovery
 
 Regardless of the primary authentication mechanism, bearer tokens and other

UserStories/PrivateSharing.md

@@ -11,10 +11,10 @@ Point 1 is just a desire. We cut point 2. into two parts: the first is uploading
 
 ### Background
 
-This story has a privacy aspect so we will use [WebID+TLS authentication](http://www.w3.org/2005/Incubator/webid/spec/tls/) to illustrate it. Other authentication methods should also work with [Web Access Control](http://www.w3.org/2005/Incubator/webid/spec/), such as WebID which is easy, and others that need to be looked at.
+This story has a privacy aspect so we will use [WebID-OIDC authentication](https://github.com/solid/webid-oidc-spec) to illustrate it. Other authentication methods should also work with [Web Access Control](http://www.w3.org/2005/Incubator/webid/spec/), such as WebID which is easy, and others that need to be looked at.
 
 
-Ian has WebID `<https://ian.name/card#me>` with a public key.
+Ian has WebID `<https://ian.name/card#me>`.
 
 ```http
 GET /card HTTP/1.1
@@ -45,18 +45,11 @@ Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
 <card#me> a foaf:Person ;
      foaf:name "Ian;
      foaf:knows <https://jane.org/profile#me> ;
-     cert:key [ a cert:RSAPublicKey;
-                rdfs:label "my laptop certificate key";
-                cert:exponent 65537 ;
-                cert:modulus "A74A4CF7BD1261D930B9656CC1A457C79ABE6F86607DB76EF95FF024CA6B712DD03DDB178669562170D7CAA8431528E1139AE85D1E72B09BD552CAD0FA94225CACA9363D799A10C0269A7DD70E28AFE0971B8352048F5DFC55537480F334155CBA98434678A887457D6378D19C8C0E9F59CA99E21492308CE4510B68C12BA3002862E30839E7D91EE0F9BF1155E07854D99FE12A32B4FB03862466203BF0E5C0D3B90B5AB6B5CABA520811FD02097CE5680C1D8B55098C566C11066B37FE43A26FCD1AA93E7A9919446F39B0E3C0D6C1C9BEB509E86255101634CBE738C52553ACC14A7FE50D536BBA5F8D96BFE0B5DA33095466B61B4141CE91405838072477"^^xsd:hexBinary;
-             ] .
 ```
 
 
 In order to be able to do command line curl demos, we will assume that
-Ian has saved his certificate and private key in the [`cert.pem`](#ians-ssl-certificate) file locally. (Of course it is not needed to do this in browsers...)
-
-The certificate public key is the one in the profile.
+Ian has already obtained a Bearer token via the [WebId-OIDC process](https://github.com/solid/webid-oidc-spec). 
 
 
 ### Ian posts the file
@@ -65,8 +58,8 @@ Here curl makes the connection, and authenticates Ian with his Certificate. As a
 
 ```sh
 $ curl -X POST -k -i -H "Content-Type: text/turtle" \
-   --cert ../eg/cert.pem:password \
    -H "Slug: financials" \
+   -H 'authorization: Bearer ey...'
    --data-binary @financials.ttl  https://ian.name/2014/   
 ```
 ```http
@@ -86,7 +79,7 @@ So the `<financials>` resource is created in the LDP container `</2014/>` . Let
 
 ```sh
 $ curl -X GET -k -H "Content-Type: text/turtle" \
-   --cert ../eg/IanCert:password \
+   -H 'authorization: Bearer ey...'
    https://ian.name/2014/financials.acl
 ```
 ```ttl
@@ -108,6 +101,7 @@ PATCH /2014/financials.acl HTTP/1.1
 Host: ian.name:443
 Content-Type: application/sparql-update; utf-8
 Content-Length: 120
+Authorization: Bearer ey...
 ```
 ```sparql
 Prefix acl: <http://www.w3.org/ns/auth/acl#> .
@@ -196,73 +190,3 @@ At this point we have the following set of links:
 ### Jane views the file
 
 Jane reads her inbox at some point, and just does a normal GET on the `<https://ian.name/2014/financials> resource, using her certificate containing a WebID.
-
-## Notes
-
-### Ian's ssl certificate
-
-You need
-
-```sh
-$ openssl x509 -in IanCert.pem -inform pem -text
-Certificate:
-    Data:
-        Version: 3 (0x2)
-        Serial Number:
-            01:49:f1:d4:3d:e6
-        Signature Algorithm: sha1WithRSAEncryption
-        Issuer: CN=WebID, O={}
-        Validity
-            Not Before: Nov 27 15:07:38 2014 GMT
-            Not After : Nov 24 15:17:38 2024 GMT
-        Subject: dnQualifier=tester@localhost.edu
-        Subject Public Key Info:
-            Public Key Algorithm: rsaEncryption
-            RSA Public Key: (2048 bit)
-                Modulus (2048 bit):
-                    00:b7:cb:16:af:0a:ee:c5:8a:4c:0c:05:e0:50:4a:
-                    33:43:82:a1:db:7a:8a:09:20:57:f9:7c:27:14:39:
-                    f7:ff:8c:fd:46:9b:61:59:34:fa:40:1b:4b:32:0b:
-                    75:6c:f0:17:e1:6c:8e:e0:d5:af:ce:ed:1a:54:39:
-                    07:38:72:0c:67:81:3b:76:5e:1b:f9:e3:10:80:9e:
-                    13:3b:7f:7c:2a:ca:34:e1:85:c3:bd:cd:42:fc:40:
-                    d8:47:72:ad:69:1f:36:b9:07:8c:8e:00:79:f6:40:
-                    89:ae:0a:dc:aa:80:d4:18:6c:f6:83:40:3d:64:85:
-                    e5:78:db:de:16:1a:82:b4:e3:46:50:cb:77:fd:27:
-                    4f:e8:4b:b7:ae:48:8a:32:36:f1:46:17:8c:f8:36:
-                    cc:70:1b:1d:3c:40:c0:d7:a8:e8:38:af:c2:09:e3:
-                    b5:c8:25:fa:97:02:01:7b:52:49:2f:4c:f4:bd:eb:
-                    08:97:26:e2:77:8e:b6:3b:88:54:c8:b3:66:b2:c5:
-                    42:5f:5d:ec:23:6c:02:c8:e7:60:b7:30:3a:df:b2:
-                    a9:4b:f8:35:c2:e2:89:01:ab:ec:a2:92:d7:ca:04:
-                    c1:ae:3c:37:7e:2d:2f:3e:01:1b:e7:68:68:d9:41:
-                    67:8a:18:c2:ab:f7:8f:98:f7:96:f4:93:f2:a9:46:
-                    cf:2d
-                Exponent: 65537 (0x10001)
-        X509v3 extensions:
-            X509v3 Subject Alternative Name: critical
-                URI: https://ian.name/card#me
-            X509v3 Key Usage: critical
-                Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign
-            X509v3 Basic Constraints: critical
-                CA:FALSE
-            Netscape Cert Type:
-                SSL Client, S/MIME
-    Signature Algorithm: sha1WithRSAEncryption
-        95:da:39:18:00:a5:7a:16:4f:cd:d2:b8:21:97:0e:e5:c7:20:
-        c1:50:21:66:e3:63:31:cf:72:f0:5b:9f:8d:57:a3:98:4f:21:
-        0f:a7:1c:3e:a3:39:64:e7:e4:ec:29:48:f7:a6:d3:fb:9c:99:
-        44:a3:44:12:3d:06:57:62:9b:9d:30:9a:7c:3c:35:6d:59:e3:
-        6e:3e:7a:e7:86:44:64:1e:16:04:8d:69:d1:f2:c4:05:e6:9b:
-        7b:f2:a4:cf:48:da:78:06:78:ff:14:be:90:b2:f7:8a:5d:ac:
-        55:da:18:25:c8:45:f1:7b:3e:f2:ab:c5:1f:13:5f:3c:9d:16:
-        a1:a8:5e:8f:4b:0c:ec:f8:71:4a:b5:86:4f:db:cd:87:c1:99:
-        75:9b:ff:34:4f:dc:da:ed:61:14:95:85:d5:6f:b3:c5:68:90:
-        9a:9f:32:23:1f:19:00:25:8c:6e:88:42:de:ad:2d:94:41:7a:
-        c4:96:6d:9f:68:a3:2f:4c:6c:99:de:6d:de:66:0f:84:fc:87:
-        9c:59:a7:d1:78:3a:5d:8d:75:32:93:a1:34:0c:b8:30:0f:ec:
-        9b:32:cc:90:b7:13:3d:a4:1f:3b:67:9a:74:ac:27:00:ed:ce:
-        0d:32:9b:f4:37:b2:18:ba:c9:49:a6:97:0c:e6:9c:e4:e9:48:
-        00:8f:df:3f
------BEGIN CERTIFICATE-----
-```

authn-webid-tls.md

@@ -97,9 +97,6 @@ statements:
   to make the display of the user's contributions identifiable.
 3. A profile MAY provide a `foaf:nick` nickname as a short string for use by user interfaces where
   space is limited.
-3. A profile SHOULD include `cert:key` public key certificate information, for
-  use with WebID+TLS (which is currently the primary Solid authentication
-  mechanism).
 4. A profile SHOULD point to the root storage location using `pim:storage`
   (so that applications will know where to read and write their data).
 
@@ -113,8 +110,6 @@ statements:
     foaf:name "Alice" ;
     <http://www.w3.org/ns/auth/cert#key> <#key6b4c> ;
     <http://www.w3.org/ns/pim/space#storage> <../> ;
-<#key6b4c>
-    # ... certificate key statements go here, see Certificates section
 ```
 
 ### Recommendation for User Names in Profiles
@@ -190,45 +185,6 @@ these cases, and also to make it extensible in future for when
 the congruent trees may be rooted in files corresponding to groups and organizations
 of which the user is a member.
 
-
-## Public Key Certificates
-
-Solid currently uses WebID+TLS as its main Authentication mechanism.
-To enable this, WebID Profile documents on Solid-compliant servers MAY contain
-one or more Public Key Certificate sections, linked to from the main WebID
-subject via `cert:key` predicates.
-
-Example profile with a public key certificate (created by LDNode):
-
-```ttl
-@prefix foaf: <http://xmlns.com/foaf/0.1/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix cert: <http://www.w3.org/ns/auth/cert#>.
-@prefix dc: <http://purl.org/dc/terms/>.
-@prefix XML: <http://www.w3.org/2001/XMLSchema#>.
-
-<https://alice.databox.com/profile/card>
-    a foaf:PersonalProfileDocument ;
-    foaf:primaryTopic <#me> .
-<#me>
-    a foaf:Person ;
-    foaf:name "Alice" ;
-    <http://www.w3.org/ns/auth/cert#key> <#key6b4c> ;
-    <http://www.w3.org/ns/pim/space#storage> <../> ;
-<#key6b4c>
-    dc:created
-       "2016-02-12T15:07:46.916Z"^^XML:dateTime;
-    dc:title
-       "Created by ldnode";
-    a    cert:RSAPublicKey;
-    rdfs:label
-       "LDNode Localhost Test Cert";
-    cert:exponent
-       "65537"^^XML:int;
-    cert:modulus
-        "970E88..(many digits here)..167801"^^XML:hexBinary.
-```
-
 ## Account Resource Discovery
 
 Solid WebID Profile documents MAY contain the following links, to support