Initial Reference Implementation of Decentralized Authentication (DID-Auth) and Authorization Mechanisms

[ccoldwell]

Value: $50,000.00Closes: Wednesday, January 31, 2018Location: Victoria In-person work NOT required

Opportunity Description

One of the key promises of decentralized identifiers (DIDs) and self-sovereign identity (SSI) is the potential for eliminating password-based authentication, particularly on websites, and the resulting improvement in online security. The human element tends to be the weakest point of any online security system and, to put it bluntly, passwords are the worst. As such, improving the human components of the online security infrastructure will have the greatest impact on improving overall online security for our citizens.

A working group in the Decentralized Identity Foundation (DIF) has been discussing the use of DIDs for authentication. A preliminary concept paper has been created stemming from discussions at the Rebooting the Web of Trust 2017 Conference as the starting point for the discussion amongst the DIF group. It appears based on the ideas outlined by the members of the DIF group, progress on the DID Spec and on the Universal Resolver for DIDs, we are at a point where a working implementation of DID-Auth would be useful.

We propose an implementation of Decentralized Identifier Authentication (DID-Auth) which we can use with TheOrgBook (described here, development instance here) website. The current and primary features of TheOrgBook are public, including searching for/discovery of organizations, displaying organizational informational, and viewing the details of an organization's verifiable claims. We also propose some initial work on Authorization using Verifiable Claims. There are several use cases related to TheOrgBook for DID-Auth, and Verifiable Claims Authorization:

Authentication Scenarios

1. System to System: Services that generate verifiable claims about organizations and write them to TheOrgBook need to be authenticated. Such Services must have a DID known to TheOrgBook and use that DID to access the Issuer API for writing verifiable claims to TheOrgBook. This would be a generic authentication method between two services at the API level.
2. Administrative: There is an administrative element of TheOrgBook that should be limited to authorized users who would have a DID.

Authorization Scenarios

1. Claim Your Claims: There is a long term desire to support verifying Organization Owners using some (likely offline) process, providing them with a Verifiable Claim that enables them to "Claim your Claims" on TheOrgBook, and thus, giving them the ability to extend their organization's TheOrgBook page (add accreditations such as the BBB, ratings, product / service information, etc.).
2. Delegation: Further, since an Organization's owner is not likely the only person associated with an organization that will need access to TheOrgBook, there will be a need to extend the authentication process to support organizational owners delegating access to their TheOrgBook page as they see fit.

We would like to explore implementing at least the first three of these scenarios using DID-Auth, and ideally all four.

For the system to system and administrative use cases, no verifiable claims are necessary for authorizations - the API and website manage authorizations of users granted access to specific capabilities. The website would maintain a user table of registered DIDs that are permitted access to the write verifiable claims and administrative features of the TheOrgBook, and a process is executed to authenticate access requests to the site. The administrative implementation must consider performance and usability for both the initial authentication process (is the process as fast/easy as passwords?) and ongoing verification (e.g. session renewal/expiration).

The "Claim your Claims" use case extends the administrative use case by adding authorization via Verifiable Claims. DID-Auth will be executed and on success, a Verifiable Claim proof process executed to determine the resources (Organizational Page and related data) to which the user will be granted access. Again, performance and usability of the process will be paramount - the user must find the process no harder than using traditional approaches. Further, the overhead on the website side - the limited per user information to be maintained - will be of interest. A goal will be demonstrating how websites can operate effectively without collecting and maintaining private information about users.

The delegation of authority use case extends the "Claim your Claims" authorization functionality by providing the Organizational Owner with the ability to delegate their access to others under their control - e.g. without having to log into TheOrgBook to record the delegation or to revoke that access. Although this use case could get into a lot of client side functionality - for example, how the Owner manages their delegations - our focus will be on the DID-Auth part of the of process and assume that the client side challenges will be handled by others.

Additional Considerations

While we know that the implementation will not be the last word in creating DID-Auth, but an initial set of steps. We would like the following considered for this implementation:

• The flows described in the docs linked in the introduction match what we are assuming will be used here. While these will be the starting point, we expect some collaboration with the community to evolve these flows, balancing the need for creating working code against the goal of creating an “ideal implementation”.
  
• The Universal Resolver will ideally be used in going from a DID to the authentication services associated with that DID.
• Ideally, a Universal Authenticator capability would be an outcome of this effort, allowing (at least for non-Verifiable Claim-based authentication) execution work across DID method implementations.
• The API/website functionality should have a minimum impact to current authentication mechanisms so as to reduce adoption effort. Ideally, the solution would be a compatible enhancement to commonly used authentication mechanisms. For example, is there a common JS library used for authentication that could be built upon to add DID-Auth functionality?
  • Note: This is just a consideration for this effort. There will not be a requirement for submitting an update to an existing library/component for this need.

Assumptions

• The implementation need not be concerned with no-Auth-related capabilities of the components. For example, although some sort of DID-capable client will be needed for demonstrating the login process, issues like general usability, scalability, and key management are not a part of this effort.
• We have full control over the code and deployment of TheOrgBook and so can be expedient in making changes to the application as necessary to support the work defined here.
• Nice to have, but not required, is an implementation of an effective “old and new” user experience. That is, the creation of a user experience that supports both password-style and DID-Auth login to the site. It is sufficient for the purposes of this implementation that TheOrgBook support only DID-Auth.

Opportunity

This is an opportunity to work with the Verifiable Organizations Network team to deliver enhancements to both a BC Government project and potentialyl an open standard.

The fixed-price reward is for a potential total of $CDN 50,000* for satisfaction of the Acceptance Criteria below, per this payment schedule:

• Completion of Phase 1 - $10,000
• Completion of Phase 2 - $5,000
• Completion of Phase 3 - $10,000
• Completion of Phase 4 - $5,000
• Completion of Phase 5 - $10,000
• Completion of Phase 6 - $10,000

* The full amount is dependent on an evaluation of outputs at the end of Phase 1, during which Verifiable Organizations Network team will determine whether or not work will continue into phases 2 and 3.

Acceptance Criteria

1. Agreed upon technical approach, implementation components, and interaction flow diagrams for the authentication only use cases - System to System and Administrative. This work needs to be shared with relevant communities with could include W3C, Decentralized Identity Foundation, Rebooting the Web of Trust or others as appropriate.
2. Working code implementing the System to System use case to protect the TheOrgBook API endpoints related to Services issuing claims to TheOrgBook. Requires code for both TheOrgBook and the VON-Connector code that Services use for issuing claims to TheOrgBook.
3. Working code implementing the Administrative use case supporting a browser-based user logging into a web session on TheOrgBook as an identified user. Requires code for both TheOrgBook and a Web App accessing TheOrgBook.
4. An agreed upon technical approach and interaction flow diagrams extending the authentication only use cases to include authorization via Verifiable Claims. This work needs to be shared with relevant communities with could include W3C, Decentralized Identity Foundation, Rebooting the Web of Trust or others as appropriate.
5. Working code implementing the “Claim your Claims” use case supporting a browser-based user logging into a web session with access to specific resources based on a Verifiable Claim held by the user. Requires code for both TheOrgBook and a Web App accessing TheOrgBook.
6. A final write up summarizing the work done, including two key elements:
   1. Post-implementation recommendations for changes/improvements to the delivered code (e.g. “what could we have done better?”).
   2. A proposed technical approach and interaction flow diagrams for the Delegation Use Case.

How to Apply

Go to the Opportunity Page, click the Apply button above and submit your proposal by 16:00 PST on Wednesday, January 31, 2018.

We plan to assign this opportunity by Friday, February 2, 2018 with work to start on Monday, February 5, 2018.

Proposal Evaluation Criteria

1. Your approach to completing the Acceptance Criteria in a short proposal (1-2 pages) which includes evidence to support the criteria outlined in items 2-5 below. Evidence can include GitHub IDs, projects for example. (20 points)
2. Your prior experience with open source projects in identity, self-sovereign identity, verifiable claims, decentralized identifiers, distributed ledger/blockchain or other relevant technologies. (30 points)
3. Your expertise in authentication and authorization protocol design and implementation. (30 points)
4. Your experience in contributing to open standards and/or open source communities (20 points)
5. Your ability to satisfy the Acceptance Criteria on or before 31 March 2018 (10 points)

[jljordan42]

Hi Everyone ... happy to answers any questions that arise from this opportunity.

[mojitoj]

Quick clarification about the timeline: Does item 5 in the evaluation criteria mean that all six phases should be completed before the end of March 2018, or only Phase 1? In other words, are you envisioning the entire project to be completed in 2 months?

[jljordan42]

Thanks for your question. The project must be completed by March 31 2018. Best John

[jljordan42]

Thanks to everyone for their interesting and bids. We are pleased to assign this opportunity to Markus (peacekeeper). If you bid and would like a debrief .. please contact me.

[ccoldwell]

This opportunity has been assigned

[jljordan42]

The work has been completed and accepted. https://github.com/topics/did-auth are the resulting repositories.