search

RubenVerborgh / solid-architecture

Drafts on the intended architecture of a concrete implementation of Solid
9 stars 3 forks source link

Close coupling of identity and authentication #3

Closed melvincarvalho closed 5 years ago

melvincarvalho commented 6 years ago

If im completely honest, this architectural design is one step forward and two steps backwards.

The main reason is that it makes the mistake, that has been almost ubiquitous, of coupling together the concept of identity and authentication, namely, verification of that identity.

Without a doubt, this has been done many times before, and we inherit from that. For example in a TLS cert the identity (subject alternative name) is coupled to the validation of that certificate.

This is horrible architecture, horrible design, and does not occur in the slightest in any of the mass communication systems that humans have used throughout the ages.

@RubenVerborgh has challenged me to come up with use cases to realize this idea. And and I will try to do so. At this point in time however, this architecture for me, is a step backwards, or perhaps sideways. ie bikeshedding

Everything else about the design I am a massive fan of. I can see many new APIs added through this scheme. ie extensibility will be incredible!

I look forward to making compelling user stories that illustrate this idea. It may take some time. Enjoying the debate!

RubenVerborgh commented 6 years ago

Hi @melvincarvalho,

Thanks for expressing this concern, we should indeed get this right. I think you can help in several ways:

  1. use cases / user stories (as you mentioned)
  2. explain how this concretely influences the architecture
  3. find out the consequences of doing things one way or another

Some feedback on your comments below.

this architectural design is one step forward and two steps backwards.

I doubt that we have “two steps backwards” compared to the current node-solid-server, since the exact same issue could be raised about that implementation. At worst, we're just not taking enough steps forward.

The main reason is that it makes the mistake, that has been almost ubiquitous, of coupling together the concept of identity and authentication, namely, verification of that identity.

I'm actually not sure this is the case. If you look into current draft, you see that we identify a piece of data we call credentials. Those credentials might or might not separate identity and authentication; it is not specified.

The important thing, however, is that the proposed architecture localizes that decision. I.e., in the current node-solid-server, that decision is spread all over different handlers. So you cannot separate identity an authentication with a small refactoring; the assumption about them being coupled or not is present in many components.

In this architecture, there is exactly one interface that needs to know about this, so it can be changed really easily. The credentials object comes out of one component, and is passed (only) to the permissions component. No other components touch upon it. So if you want to separate or join them, only this single interface is affected. I would say that's a major step forward.

This is horrible architecture, horrible design, and does not occur in the slightest in any of the mass communication systems that humans have used throughout the ages.

What would really help me is that if you could explain concretely what a separation of identity and authentication entails.

One proposal was to, in concrete implementations, design credentials such that it has an identity part (WebID string) and an authentication part (object detailing how the user was authenticated, e.g., password, two-factor…). Does this address your issue? If it does, note that this is not in contradiction with the current architecture.

melvincarvalho commented 6 years ago

Firstly, apologies if some of the points I raised were overstated, thank you for the measured response! I'm now over my wave of world cup related depression -- congrats to your team on beating ours! :)

Back to the topic ... I really wanted to create a place holder for some of the discussions we had in the chat room, and to record user stories. There was also some desire to do cost benefit analysis of different types of refactoring (ie small vs large).

I'm actually not sure this is the case. If you look into current draft, you see that we identify a piece of data we call credentials. Those credentials might or might not separate identity and authentication; it is not specified.

I think this being the case would be really good. So you can have a credentials object (right now we have just a single webid variable iirc), then you have authentication information e.g. how was the webid verified oidc / tls / cookie / force-user other information maybe such as you may have a valid certificate key but expired -- do we want to allow that etc.

So, one example that springs to mind is email. It's possible to verify who sent an email, but most of the time it is not done at all. However, it's difficult to argue knowing who sent you an email is not valuable information (even if unverified).

One proposal was to, in concrete implementations, design credentials such that it has an identity part (WebID string) and an authentication part (object detailing how the user was authenticated, e.g., password, two-factor…). Does this address your issue? If it does, note that this is not in contradiction with the current architecture.

This would be imho perfect.

I do like most of what is here. And I also have some use cases regarding payments which could extend the API system. But that's for another thread.

use cases / user stories (as you mentioned)

I will add each use case as a separate response, perhaps, at this point, only for documentation sake.

kjetilk commented 5 years ago

Oh, I didn't see this comment before now. Actually, @RubenVerborgh and I discussed this F2F yesterday. So, the current NSS doesn't get this right either, so it can't possibly be a step back.

But we really have the chance now to take a big step forward, and I hope we can achieve that. I see the need for having the backend just relate to a WebID, and that's it. In front of it, it seems like we need to support several authn, TLS, OIDC and SAFE comes to mind immediately, and then DID is likely to come our way, and there are likely more coming up. To me, that seems like the most unchartered territory we have going forward.

There has been some mentions of that we should have ACLs based on how the user was authenticated (e.g. simple username/password vs a good multifactor authentication). I think it is inevitable that users will have several WebIDs, for the simple reason that a WebID is itself personally identifable information, and so to ensure that users aren't tracked when they don't want to, they need many WebIDs. To simplify, I think that we might just have different WebIDs backed by different authn. And then, we should enable some inference about different WebIDs belonging to the same person, when that can be done without compromising user privacy.

It seems to me that a large number of authn schemes can be problematic, because clients and servers will have to support them all to avoid a fragmented Web. How we solve that, I don't know, but from the sound of it, it sounds like rather having them go through OIDC might be a way forward.