Holder Authentication - Request and Response
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 19
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
Discussion at in-person meeting on 8/31.
The desire is to avoid scenarios where individuals are subjected to server side biometric matching by RPs due to insufficient indications of what authentication occurred. This could be achieve a number of ways, but the intent is to allow for a request and response model where the RP can indicate a preference for a specific holder authentication type. The wallet will then indicate what authentication type occurred or whether the preference was met. If a wallet cannot achieve the desired authentication level the RP can then decide what to do with the information.
This was substantially informed by feedback from US financial institutions over concerns around having no visibility into how the holder is authenticating at transaction time.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or implementation entry points are identified in the issue; start by clarifying the proposed request and response model with the DCHP working group. Done should define how an RP expresses a holder-authentication preference and how the wallet reports the authentication type or whether that preference was met.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100