search

namebasehq / handshake-id-manager

MIT License
30 stars 7 forks source link

What's the protocol's default _idmanager #8

Open Falci opened 3 years ago

Falci commented 3 years ago

When the user starts the login flow, the OIDC should query for the TXT record on _idmanager.<name>'s DNS. What happens if the name has none?

Namebase's OIDC default action is to send the user to id.namebase.io which is Namebase's id manager. However, during the registration process, this id manager asks the user to add only the device/fingerprint DNS record, keeping the id manager undefined. If later, the same user tries to login using the same name, in a different website (that has its own OIDC) it won't be possible to know its idmanager.

  1. Should we assume that no idmanager means id.namebase.io?
  2. Is id.namebase.io open and expecting signing request from 3rd-parties, other than oidc.namebase.io?
  3. Shouldn't id.namebase.io also asks its users to add the _idmanager DNS record?
jeefave commented 3 years ago

The thought process on keeping the value undefined is to let a specific oidc provider handle their own default. A different OIDC provider could default to a different id manager.

The intent is to leave the separation of concern between the oidc provider and the id manager so the TXT _idmanager is being defined by the user intentionally and not being driven by the oidc component. To answer the point 3, yes the id manager should be the one responsible to prompt the user to set the TXT records for _idmanager. In the future id.manager.io could have an "eject" feature to set a custom _idmanager and deploy on heroku, s3, skynet, ...

The protocol does not impose a particular id manager. The implementation however requires a fallback. I am not sure the protocol necessarily requires a default value but I am curious to hear your thoughts if it has further implications. If the user did not decide to aggregate his identities into a custom identity manager, the oidc provider is in charge of defining its own fallback, this can be id.manager.io or a custom one. id.manager.io can totally be reused by other oidc provider. This would be an implementation decision.

Falci commented 3 years ago

If the user has used an OIDC, it MUST have use an idmanager as well. Probably the default for that OIDC, which is ok. But that also means the user trust in the idmanager, also ok; Any other OIDC (which has a separated concern from idmanager) should be able to use the previous and already trusted idmanager.

If every OIDC takes the same path as id.namebase.io of "if not set, use the default" the user will end up with a lot OIDC specific config, which could be avoided. And when a new OIDC decides not to use default values and asks the user to explicitly set an idmanager, all the other setup (individual OIDC's default idmanager) will be useless

Just ask your users to set their idmanager, what's the problem with that?

jeefave commented 3 years ago

No problem with that quite the opposite! It has been considered as a future implementation but we have competing priorities at the moment. The release of the source code of the oidc provider is due. I hope it will help to submit PRs implementing these improvements.