Skip to content
This repository was archived by the owner on Apr 13, 2022. It is now read-only.

Removed references to TLS as primary auth method #171

Open
jaxoncreed wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Removed references to TLS as primary auth method #171

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5f2f6db
Removed references to TLS as primary auth method
jaxoncreed May 14, 2019
49db97f
Brought back TLS as a MAY
jaxoncreed Jun 27, 2019
e9a13c7
Added tls back to examples
jaxoncreed Jun 27, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 17 additions & 32 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down Expand Up @@ -106,7 +105,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
Expand All @@ -120,43 +119,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

Expand Down
88 changes: 6 additions & 82 deletions UserStories/PrivateSharing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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#> .
Expand Down Expand Up @@ -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-----
```
24 changes: 0 additions & 24 deletions authn-webid-tls.md
View file
Open in desktop

This file was deleted.

44 changes: 0 additions & 44 deletions solid-webid-profiles.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Copy link
Contributor

@michielbdejong michielbdejong Jun 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAY

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).

Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down