solid · jaxoncreed · May 14, 2019 · Jun 27, 2019 · Jun 27, 2019
diff --git a/README.md b/README.md
@@ -14,9 +14,8 @@
     * [WebID Profile Documents](#webid-profile-documents)
 4. [Authentication](#authentication)
     * [Primary Authentication](#primary-authentication)
+      * [WebID-OIDC](#webid-oidc)
       * [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)
@@ -74,8 +73,7 @@ location of a public [WebID Profile document](#profiles) (see below).*
 
 ## Profiles
 
-Solid uses WebID Profile Documents for management of user identity and security
-credentials (such as public keys), and user preferences discovery.
+Solid uses WebID Profile Documents for management of user identity and optionally security credentials (such as public keys), and user preferences discovery.
 
 Although here we mostly refer to them in the context of user profiles,
 other types of actors use these profiles as well, such as groups, organizations,
@@ -106,7 +104,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,43 +118,29 @@ 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.
 
+Implementations of WebID-OIDC IDPs for Solid SHOULD implement TLS as a login method
+alongside other login methods such as passwords.
+
 **See component spec:
   [WebID-OIDC Specification](https://github.com/solid/webid-oidc-spec)**
 
-#### Alternative Authentication Mechanisms
+#### WebID-TLS (Optional)
 
-There are several other authentication mechanisms that are
-currently being investigated, such as combinations of traditional
-username-and-password authentication and WebID-TLS Delegation).
+**Note:** Several browser vendors (Chrome, Firefox) have removed support
+for the `KEYGEN` element, on which WebID-TLS relied for in-browser certificate
+generation.
+
+Solid servers MAY implement the [WebID-TLS
+protocol](http://www.w3.org/2005/Incubator/webid/spec/tls/) as one of their
+primary authentication mechanisms.
+
+**See component spec:
+  [Solid WebID-TLS Specification](authn-webid-tls.md)**
 
 ### Secondary Authentication: Account Recovery
 

diff --git a/UserStories/PrivateSharing.md b/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: [email protected]
-        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-----
-```
diff --git a/authn-webid-tls.md b/authn-webid-tls.md
@@ -21,4 +21,4 @@ publish in their WebID profiles.
 The tech at work here is the familiar [TLS
 protocol](https://en.wikipedia.org/wiki/Transport_Layer_Security) used by
 browsers to establish secure HTTPS connections to known websites, but with two
-important differences. 
+important differences. 
diff --git a/solid-webid-profiles.md b/solid-webid-profiles.md
@@ -97,10 +97,10 @@ 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
+4. A profile MAY 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`
+5. A profile SHOULD point to the root storage location using `pim:storage`
   (so that applications will know where to read and write their data).
 
 ```ttl
@@ -193,7 +193,7 @@ of which the user is a member.
 
 ## Public Key Certificates
 
-Solid currently uses WebID+TLS as its main Authentication mechanism.
+Solid currently supports WebID+TLS as an optional 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.