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

Support did:x509 in Authorization Server metadata #3573

Merged
merged 3 commits into from
Nov 21, 2024
Merged

Conversation

reinkrul
Copy link
Member

Allowing credentials to be issued from it.

This is probably not the right solution, since the actual issue is that didmethods indicates 2 things:

  • DIDs the Nuts node creates for its subjects
  • DID methods it accepts when other parties present credentials

These should probably be 2 lists. The 2nd list could actually be all supported DID methods (nuts, web, x509, jwk, key) minus those we can't resolve if not configured properly (nuts).
@woutslakhorst ?

@woutslakhorst
Copy link
Member

The static set (resolvable by code) of jwk, key and x509 should always be added. This is also true for the discovery service definition did_methods

@reinkrul reinkrul marked this pull request as ready for review November 19, 2024 17:07
@reinkrul reinkrul changed the title Support did:x509 in Authorization Server metadata, Support did:x509 in Authorization Server metadata Nov 19, 2024
@reinkrul
Copy link
Member Author

Discovery has slightly different rules, made an issue #3575

Although Discovery might not actually need did_methods, and could use a prefix with wildcard in PEX..

auth/auth.go Outdated
return auth.supportedDIDMethods
// DID methods that don't require additional resources/configuration in the Nuts node are always supported.
// Other DID methods (did:nuts), are only supported if explicitly enabled.
result := []string{didweb.MethodName, didjwk.MethodName, didkey.MethodName, didx509.MethodName}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did:web can also be disabled

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking out loud: what would be the use case for NOT accepting did:web credentials?

  • did:web is arguably unsafer compared to jwk, key, x509 (since these aren't suspectible to network-bound attacks, e.g. DNS or domain hijacking). So verifiers might not want to accept it.
  • On the other hand, parties might want to accept it but might not want their Nuts node to create did:web DIDs.

Both are edge cases i.m.o., but I think the first argument is more credible. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently our config defines it as on/off per method, for issuance, holding and verifying. It would be best to not differentiate between the behaviour of did:web and did:nuts

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, will do the same for did:web then

@reinkrul
Copy link
Member Author

Updated

@reinkrul reinkrul merged commit 051b282 into master Nov 21, 2024
9 checks passed
@reinkrul reinkrul deleted the didx509-fix branch November 21, 2024 05:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants