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

Who is the ARKG subordinate party #28

Open
sander opened this issue Jun 10, 2024 · 1 comment
Open

Who is the ARKG subordinate party #28

sander opened this issue Jun 10, 2024 · 1 comment

Comments

@sander
Copy link
Owner

sander commented Jun 10, 2024

During the 2024-06-10 meeting, @ve7jtb mentions regarding #15 that we should reconsider who the WSCA delegates key generation to:

  • the relying party (as in the current draft)
  • the wallet provider
  • possibly also the wallet instance?

This needs a design decision. So far, I chose to delegate to the relying party in order to enable issuance in multiple batches.

@sander sander moved this to To do in HDK coordination Jun 10, 2024
sander-cb pushed a commit that referenced this issue Jun 29, 2024
Basic HDK is now more like BIP32. ARKG is available for cases
where the instance indeed wants to delegate key generation.
The spec now does not preclude any document authentication
mechanism, so it is applicable to both single-release documents
as well as to for example BBS#. It also does not preclude
delegation to other parties, such as the solution provider.
@sander
Copy link
Owner Author

sander commented Jul 1, 2024

Discussed 2024-07-01: as of 6a990e4, the core HDK spec is neutral towards who is the ARKG subordinate party. We may provide some examples in the section on Application considerations.

@sander sander moved this from To do to Later in HDK coordination Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Later
Development

No branches or pull requests

1 participant