Delegation of Authority for Organizations + Services w/DID’s + VerfCreds

From IIW

Delegated Authority using DIDs and Verified Credentials

Thursday 5G Convener: Stephen Curran, John Jordan BC Government

Notes-taker(s): Stephen Curran, BC Government

Tags for the session - technology discussed/ideas considered:

#delegation #sovrin #verifiablecredentials #hl-indy #bcgov

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: The session began with a presentation/strawman of a proposed approach to the issue (background, challenges, goals and proposed approach) and continued with a discussion of the pros, cons and improvements on the proposal.

tl;dr - The goals of the approach are worth achieving, and the mechanisms proposed can work. However, the use of DIDs and Verifiable Credentials are not required for the approach to work. Other mechanisms (SAML tokens, JWTs) that have the same "proof attributes" of Verifiable Credentials would work just as a well. The proposed implementation of capabilities is both sufficient for simple implementations and arbitrarily extensible.

For practical implementations allowing arbitrary chains of delegation, it would be useful to embed the full chain of proofs to prevent the need to retrieve and query each proof interactively from the delegates involved in the chain.

Background

The presented discussion will be Hyperledger-Indy (Sovrin)-centric - because that is what we’re using on our project

There is an associated, evolving paper about this that describes the mechanism:

Delegated Authority Capabilities using Verifiable Credentials (https://docs.google.com/document/d/1yZaBGWHv-ogzN6S2wZ95d1T_Ykeq0GTGGZv9trGc6Ws/edit?usp=sharing)

HyperLedger Indy's implementation of Verifiable Credentials (called "anoncreds" in Indy) are the “transport mechanism” for delivering the Delegated Authority

  • They are not being used in this overview to (for example) proof Experience/Academic Credentials, etc.
  • That is a parallel, but separate, issue from Delegation of Authority

Challenge

  • Organizations are made up of people
    • Some inside the organization, some outside
    • A person can be "Organization" - delegating authority to family members, powers of attorney, etc.
  • Services offer capabilities to the Organization
  • People access Services to work on behalf of the Organization
  • Organizations delegate authorization to people based on their function
    • What capabilities they are permitted to perform on the service

Current models:

  • Services don’t offer delegation - accounts are shared
    • Simple - share passwords (Really Bad!)
    • Sophisticated - controlled account available for multiple people - e.g. Hootsuite-controlled access to an Company's official Twitter account
  • Services provide functionality to allow Organizations to manage Delegation - for that Service
    • In the government - every Service does this

Goal:

  • Enable access to a Service by the Organizations, not to individuals
    • Simplify Service “User Management” functionality - track the Organization, not the individuals using the account
  • Enable the Organization to Delegate Authority - inside the Organization
  • Enable the Service to express the Capabilities they offer and understand
  • Enable a Delegation protocol
    • Organization Delegates Capability X to Person Y
    • Person Y accesses Service for Capability X on behalf of the Organization

Verifiable Credentials - Important Attributes

  • Uses the W3C-Model of Issuer, Holder and Verifier
  • The verifier can prove:
    • The data was not tampered with
    • Who issued the data
    • That the data was issued to the Holder
    • That the data can be checked for Revocation in real time

Mechanism - Registration

  • Organization establishes relationship with Service
  • DIDs are exchanged as IDs for each party - Organization and Service
  • Service retains DID of Organization
  • Service provides Organization with list of Capabilities
  • Aside: Traditional Handling of this in Government Services
    • Functionality offered to users are controlled by Permissions
      • Eg. List Transactions, Create Transaction, Print, etc.
    • Arbitrary Roles can be defined as a set of Permissions
    • We envision for Government Services, the expressed Capabilities will be "Roles" understood in the Business Context
      • E.g. for the "Patent Office" Service, the roles are "Patent Attorney", "Inventor", "Paralegal"

Mechanism - Delegation

  • Organization uses a common schema (format of Verifiable Credential) to issue a Verifiable Credential to a person
    • Assumes a relationship between person and Organization
  • Verifiable Credential schema includes:
    • Service Name
    • Issuer Name
    • Capability(ies)
    • Signed DID of Issuer
    • Optional - Identifier of Delegate (Organization ID, Name, etc.)
  • Delegate may issue a Verifiable Credential to others...and so on
    • Attorney to Paralegal - perhaps with a subset of Capabilities

Mechanism - Login

  • Delegate initiates login to Service
    • Not recognized
  • Service requests Proof of Delegated Authority
  • Delegate provided proof of issued Verifiable Credential
  • If necessary - Follow chain of Proofs to get to recognized Issuer
  • Check revocations
  • Recognize identity and capability
    • Organization
    • Delegated Capability(ies)
  • Separate Issue - May require other Proofs to use the Service
    • Eg. Capability to use “Patent Attorney” capability may also require Proof of Attorney in Good Standing from the Bar

Improvements/Optimizations:

  • “Delegateable” flag - prevent chain of delegation
  • Hyperledger - Indy - normal flow is for each Issuer to have a published (on ledger) DID and Credential Definition on Ledger
    • Could instead, embed the DID Public Key, and Credential Definition in the Verifiable Credential so the Service receives the full chain
    • Still has to check revocation for each Issued credential in the chain

Observations from the Discussion: The general feeling was that the proposed flow is appropriate. However, the use of DIDs, decentralized ledgers, and Verifiable Credentials (as defined by W3C or Hyperledger Indy) are not required. There are other mechanisms that could be used that they have the same "proof" attributes of Verifiable Credentials (listed above), including SAML tokens, JWT, etc.

We also agreed that the underlying transport mechanism for the Delegated Capabilities (e.g. Verifiable Credentials, SAML Tokens, JWT) should have a native credential expiration mechanism. This will reduce the instances of revocation for routine handling of the delegation.

The Capabilities model that we describe above (the "Permissions and Roles" model commonly used by Government Services) could be made arbitrarily more complex, depending on the domain, complexity of the use case and the effectiveness of the user interface in supporting users. However, we agreed that is an "implementation detail" that does not affect the proposed mechanism. Having said that, if there is a goal that such a Delegation Protocol be generally deployed and used across Services, we will want constraints to support interoperability. For example, if the User Interface used to delegate authority for the Organization is an Active Directory-type application that maps Service Access to People, then supported Services will have to express the offered Capabilities and understand the presented Delegations in standard ways.

Harri Honko (Tampere University of Technology) has implemented this mechanism using Hyperledger Indy and standard W3C Credentials in a slightly different use case:

  • A Electric Utility Service stores data about a user in their system - in this case Electricity usage
  • A user wants to provide an Application limited access to their data on the Service
  • The user Delegates Authority to the Application via a W3C Verifiable Credential
  • The application presents that Delegation to the Service and is given access to an API to access the user's data.

A full presentation on Harri’s use case and implementation can be found here: https://docs.google.com/presentation/d/1aeWAexMmD0rBNAmS_mNvZwf_0xHVfxD4j7N6LRI5SGg/edit#slide=id.g373a1094a5_0_0 As well, here is a link to the implemented code: https://github.com/TrustNetFI/authcred-demo

The following is the W3C Standard Verifiable Credential used: 

{
  "@context": [
	"https://w3id.org/credentials/v1",
	"https://example.com/credentials/v1",
	"https://w3id.org/security/v1"
  ],
  "type": [
	"Credential",
	"DelegatedAuthorityCredential",
	"CustomerIdentityCredential"
  ],
  "claim": {
	"id": "TaVE1pAaummu3wfbWtVbyu",
	"claim": {
  	"authorizedscopes": ["electricity_metering_data",”read_access”],
  	"customerid": "192873465"
	}
  },
  "issuer": "VJkTdbQZTRnJneZAR245n6",
  "issued": "2018-04-04",
  "credentialStatus": {
	"revocation": "http://example.com/revocation/c73fcffb-5cb0-4bc4-b97c-816048166cbf"
  },
  "signature": {
	"type": "Ed25519Signature2018",
	"creator": "VJkTdbQZTRnJneZAR245n6#key1",
	"created": "2018-04-04T12:18:44.202Z",
	"domain": null,
	"nonce": "c73fcffb-5cb0-4bc4-b97c-816048166cbf",
	"signatureValue": "SeZ0fqLYteuVBa7WI27dQcJPy0lS0CC3vuyvqsa9AqXDUVfX91hKSwgpwUnn9l7l0EBBcPz6CqDkI1gzmAfMBw=="
  }
}

Harri's approach is a vast improvement over, for example, the current Mint cloud service that operates by getting your "normal" Banking Credentials (userID and Password) to download, analyze and present your financial information. Those credentials give Mint and comparable services full access to your Banking capabilities - download and create transactions - vs. only the download transaction history needed to operate the Mint service.

Retrieved from "https://iiw.idcommons.net/index.php?title=Delegation_of_Authority_for_Organizations_%2B_Services_w/DID’s_%2B_VerfCreds&oldid=21601"