Skip to content
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

Clarification of other verification methods in authentication section missing #57

Open
awoie opened this issue Sep 27, 2019 · 4 comments
Assignees
Labels

Comments

@awoie
Copy link
Contributor

@awoie awoie commented Sep 27, 2019

The spec allows other verification methods than public keys:

The value of the authentication property SHOULD be an array of verification methods.

Furthermore ...

Each verification method MAY be embedded or referenced. An example of a verification method is a public key (see Section § 5.3 Public Keys ).

We should clarify the extension mechanism for other verification methods:

  • will there be a registry?
  • will there be a type?
  • can you give an example of another verification method?
  • ...
@awoie awoie changed the title Clarification of other authentication methods in authentication section missing Clarification of other verification methods in authentication section missing Sep 27, 2019
@msporny msporny added the discuss label Oct 1, 2019
@dlongley

This comment has been minimized.

Copy link
Contributor

@dlongley dlongley commented Oct 8, 2019

Authentication is not a "verification method", but a purpose for which a proof may be created. A DID Document expresses authorized verification methods for specific proof purposes, such as authentication. So the DID Document contains properties that are proof purposes with values that are verification methods (e.g., specific public key instances). For example:

{
  "@context": "...",
  "id": "did:example:123",
  "authentication": [ /* list of public keys that are authorized by 'did:example:123' for creating proofs for the purpose of authentication */],
  "capabilityInvocation": [ /* list of public keys that are authorized by 'did:example:123' for creating proofs for the purpose of capability invocation */],
  "assertionMethod": [ /* list of public keys that are authorized by 'did:example:123' for creating proofs for the purpose as a method of assertion (think VCs) */],
  "..."
}

We should be able to crib from this email to create some text to better explain this in the spec:

https://lists.w3.org/Archives/Public/public-credentials/2018Dec/0108.html

@awoie

This comment has been minimized.

Copy link
Contributor Author

@awoie awoie commented Nov 4, 2019

@dlongley According to the current spec text, my assumption was that the authentication section could use other entries than public keys as well. Some of them might not even relate to keys in the publicKey section. Would you agree with that? If this is the case, we should define rules how these can be represented.

@dlongley

This comment has been minimized.

Copy link
Contributor

@dlongley dlongley commented Nov 4, 2019

@awoie,

According to the current spec text, my assumption was that the authentication section could use other entries than public keys as well. Some of them might not even relate to keys in the publicKey section. Would you agree with that?

Yes.

If this is the case, we should define rules how these can be represented.

At a minimum we should certainly give examples, discuss extensibility, and perhaps informally link to other specs.

@awoie

This comment has been minimized.

Copy link
Contributor Author

@awoie awoie commented Nov 4, 2019

@dlongley I thought that this might be a way to represent the ethereumAddress and other "things" that don't encode actual public keys. Then, we won't have to deal with that in the publicKey section. Do you think that this is a viable approach?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.