-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
…ls to be issued issued from it
The static set (resolvable by code) of jwk, key and x509 should always be added. This is also true for the discovery service definition |
Discovery has slightly different rules, made an issue #3575 Although Discovery might not actually need |
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} |
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.
did:web can also be disabled
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.
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?
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.
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
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.
Ok, will do the same for did:web then
Updated |
Allowing credentials to be issued from it.
This is probably not the right solution, since the actual issue is that
didmethods
indicates 2 things: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 ?