Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identity RFC & Research #15
base: master
Are you sure you want to change the base?
Identity RFC & Research #15
Changes from 9 commits
034c894
9cecc0f
cfc5224
d60ff8e
d38de04
38c4225
4298dc4
f0c71e7
236604e
b6d6880
023dd5c
fbdab97
da3b625
3482de3
72a173b
6ad7491
c3e5a9d
8e2ed22
2ad6cbf
8a84718
c249510
4a9e620
16d50bf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jonnycrunch, @b5, @ianopolous would love your review on this RFC, I know that you have been thinking about Identity on the Decentralized Web a ton :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lanzafame just read up ipfs/notes#292, you should review this one too! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
revocation is MUST, whereas recovery is optional, see here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct, thanks for pointing that out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence sounds like Alice has given herself a present containing a DID, device key and claims. I could be incorrect, but I am guessing the gist of it is that Alice presents herself as herself to Bob with these things.
Long way to say that the sentence could be made clearer, whichever way it is meant to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed
presents
tointroduces
to avoid confusion.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is communicating with an IdentityManager from something other than a browser within scope of this document?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've mentioned that briefly in the IdentityManager introduction:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't explored situations where the user wants to authenticate to a dApp, via another device. Were you mentioning that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more referring to something you addressed above:
That answers my question. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is an extra
it
in the sentence.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Associate existing keys" implies duplicate use of keys across services? It's worth considering the attack vector of app developers knowing both a secret and where to use it as part of the key association process.
If keys aren't moving / duplicating, then we lose the underlying assumption that the private keys live withing IdentityManager, which'll drive implementation complexity up a bunch if one intends to keep the experience for app developers smooth.
Some of this may be better covered in the verifiable claims spec, apologies if this is out of scope / covered elsewhere 😄. Seems like derivative keys are once again the answer, but worth calling out explicitly if so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on the DID method, associate existing ones means one of:
1
is preferable but2
is the only viable option for some DID methods. You may read more on https://w3c-ccg.github.io/did-spec/#authorization-and-delegation.The Device & Session private keys live within the IdentityManager and dApps must use the IdentityManagerClient to sign/decipher payload. I didn't understand why is this related with the verifiable claims, is it because of the signatures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how this would work: all of the
private keys
are encrypted with theDevice Public Key
. I think all of thekey wrapping
will have to work via a symmetric PBKDF2 key as you are wrapping the private keys (needed to decrypt the private key material) with a public key. Won't one need the wrapped private keys to do the decryption?(Luckily, mobile devices have the excellent UX of fingerprint and face-unlock that can extract the symmetric wrapping key from the device's
secure enclave
, on desktop, this is less tidy. I hope I am not getting too deep into implementation here).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could a third option be to issue a one-time-use key? I've used json web tokens in the past for such a purpose back when they were considered a good idea.
For this to work one would need to scope the capabilities of such a key, or place a reasonably-short TTL on the key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will answer below as it is related.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I'm secretly hoping for a parallel document for defining d.app capabilities, which in this context would be classified as an artifact, but intersect at the point of permissions.
This document seems to carry forward the assumption that I want to orient my experience of d.apps around the present model of sign-up-for-service-and-stay-signed-up. As a user I want to live in a world where if I stop using a service after a while, it's capacity to act on my behalf (sessions) is reduced without my intervention.
This will greatly frustrate app developers if presented directly, but a smooth-enough cross-app authentication interface coupled with a well-defined capabilities spec would make it possible for app developers to build upon each-other's features. Github & Continuous Integration feels like the prototype for this, where two app developers have a strong mutual interest to build on each-other's work because continuous integration is a big problem, and code management is a big problem.
I want to live in a world where authentication & capability definition is so well defined I don't have to build a chat feature into my app, instead I can just rely on some other app's implementation. For that to work we need uniform identity management & a common method for defining the capabilities of a d.app. The IPFS project is a bold step for common infrastructure that makes much of this conversation possible, if only a dream at this point 😉.
Amazon Temporary Security Credentials and it's STS service come to mind as non-oAuth prior art.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Me, @joaosantos15 and @pgte were also working on a Authorization RFC that would be built on top of this document.
That's right. As of now, the only way for the application to act on your behalf is to sign artifacts that are meaningful in the context of it, like creating a comment in a discussion and sign it. But because this all happens in the browser environment, if you just do not use the app, the app code won't be acting on your behalf without you noticing it. There's an exception, which is if an app tries to sign stuff within ServiceWorkers, but we can handle that gracefully by notifying the user if the app is doing it regularly in the background.
It seems that you are referring to situations where a person authorizes a application, similar to oAuth, and then the application may initiate actions on the person's behalf without the user being interacting with the app. This is out of the scope of this RFC for now. If you are indeed referring to this kind of situation, there's some overlapping with identity hubs's actions & permissions. We could study it and mention it in this RFC for such situations.