Removed references to TLS that imply it is the primary form of authenication #26
Conversation
|
👍 looks good. |
|
@jaxoncreed ping |
|
@dmitrizagidulin @michielbdejong could you give this a review so I can merge it? |
|
@kjetilk I think you have write access to this repo, can you add your review? |
|
also @RubenVerborgh please re-review |
|
@kjetilk @Mitzi-Laszlo @timbl @justinwb: we need one more of you to approve this before it can be merged. |
|
Actually, I have no strong opinions, but this has such a long history that I think @timbl 's review would be good to have for legitimacy. |
What does that mean, in regards to your DiD reference? Solid has historically supported WebID-TLS or WebID-OpenID Connect as authentication protocols. Why do we need to go down the problematic maze associated with designating WebID-OpenID Connect as the Primary Authentication Protocol? That's simply wrong, and by now the experiences to date should be ample evidence. Experiences to date meaning:
|
|
Note: I approved for technical correctness, but this should not be merged without approval from @timbl indeed. WebID-TLS has some very nice technical properties; the only blocker is the extremely bad browser UI (which is so bad that it is currently virtually impossible to use it with many sources, as we will have with Solid). At the same time, we have the One Solid notion. So not an easy decision at all. |
|
Situation Analysis Solid seeks to simplify (via frameworks, libraries etc) the development and deployment of read-write applications that leverage Linked Data principles. As part of the endeavor outlined above, loose-coupling of Identity (via resolvable identifiers i.e., WebID), Identification (profile data i.e., WebID-Profile Document), authentication (via authentication protocols e.g., OpenID Connect and TLS), and authorization (via WebACLs) are essential regarding architecture dexterity and vision consistency. Challenge What MUST application developers expect in order to provide solutions to end-users en route to providing the most flexible and usable experience possible? Suggested Solution Here's a table reflecting both what exists across protocols and developer profiles using a MAY, SHOULD, or MUST approach to authentication protocol support i.e., what needs to be reflected in literature that informs rather than confuses the broader Solid Community.
|
|
@kidehen That sounds like an acceptable solution, though I think I'd upgrade OpenID Connect to a MUST (since it's already implemented for the OpenID Connect + TLS Bridge). Would you mind making those modifications to the spec then linking that pull request here? |
|
|
This PR only corrects the context about webid-oidc-spec, the mention of "secondary" webid-tls as per that table will go into solid/solid-spec#171 |
There was a problem hiding this comment.
LGTM, with the side note that we should take into account @kidehen's point when formulating solid/solid-spec#171
|
@timbl can we merge this now? This only removes references from this spec, the bigger change is in solid/solid-spec#171 |
TLS as a primary form of authentication should be deprecated in favor of a oidc. TLS may still be used as a form of credentials under oidc. All concerns about needing completely decentralized identity systems will be solved with an eventual implementation of DiD.