diff --git a/README.md b/README.md index d2e6f8e..bbe2350 100644 --- 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 index ce81664..9f1489e 100644 --- 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 `` with a public key. +Ian has WebID ``. ```http GET /card HTTP/1.1 @@ -45,18 +45,11 @@ Link: ; rel="type" a foaf:Person ; foaf:name "Ian; foaf:knows ; - 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 `` resource is created in the LDP container `` . 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: . @@ -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 ` 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----- -``` diff --git a/authn-webid-tls.md b/authn-webid-tls.md index c0987a1..8b99bcb 100644 --- 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. \ No newline at end of file diff --git a/solid-webid-profiles.md b/solid-webid-profiles.md index c1f7433..24e5b51 100644 --- 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.