Warning:
This wiki has been archived and is now read-only.

ProposalsQ42015/VCTFWorkPlan

From Web Commerce Interest Group
Jump to: navigation, search

Verifiable Claims Task Force

Please read the Verifiable Claims Task Force proposal page to get an idea of what the group is supposed to be working on. This page details those work items.

Open Questions

A number of open questions have been identified as good starting points for discussion in the space:

  • Why does this problem exist today?
  • Should verifiable claims be service-centric (like OpenID Connect), or should they be user-centric (Credentials CG demo)?
  • Should there be a standard way of expressing verifiable claims (e.g. educational transcripts, professional licenses, KYC information, government IDs, etc.)?
  • How are verifiable claims issued to entities?
  • Where are verifiable claims stored?
  • How does an entity request verifiable claims from another entity?
  • How are verifiable claims revoked by the issuer?
  • Does the web browser have a role to play in this ecosystem (via native browser APIs)?
  • How are verifiable claims moved from one storage provider to the next?
  • What are the privacy concerns and implications of the known architectures?
  • Are portable identifiers a part of the solution? Are service-centric identifiers a problem (if so, what about them are problematic)?
  • Is W3C the right place to do this work? Does it have the right people and skillset to succeed?

Other Initiatives

  • SAML
  • OpenID Connect
  • IDMix
  • Liberty Alliance
  • NSTIC Identity Initiative
  • PSD2
  • FIDO
  • OAuth2

Concerns

  • Regulation
    • What national laws regulate to the collection and use of personal data?
    • To whom do the laws apply?
    • What data is regulated?
    • What acts are regulated?
    • What is the jurisdictional scope of the rules?
    • What are the main exemptions?
    • Is notification or registration required before processing data?
  • Main data protection rules and principles
    • What are the main obligations imposed on data controllers to ensure data is processed properly?
    • Is the consent of data subjects required before processing personal data?
    • If consent is not given, on what other grounds (if any) can processing be justified?
    • Do special rules apply for certain types of personal data, such as sensitive data?
  • Rights of individuals
    • What information should be provided to data subjects at the point of collection of the personal data?
    • What other specific rights are granted to data subjects?
    • Do data subjects have a right to request the deletion of their data?
  • Security requirements
    • What security requirements are imposed in relation to personal data?
    • Is there a requirement to notify personal data security breaches to data subjects or the national regulator?
  • Processing by third parties
    • What additional requirements apply where a third party processes the data on behalf of the data controller?
  • Electronic communications
    • Under what conditions can data controllers store cookies or equivalent devices on the data subject's terminal equipment?
  • International transfer of data
    • What rules regulate the transfer of data outside your jurisdiction?
    • Are data transfer agreements contemplated or in use? Have any standard forms or precedents been approved by national authorities?
    • Is a data transfer agreement sufficient to legitimise transfer, or must additional requirements (such as the need to obtain consent) be satisfied?
    • Does the relevant national regulator need to approve the data transfer agreement?
  • Enforcement and sanctions
    • What are the enforcement powers of the national regulator?
    • What are the sanctions and remedies for non-compliance with data protection laws?

Desired Characteristics

The following features have been identified by the industry survey as desirable:

  • A standard data format for a credential container
  • Issuing verifiable credentials (e.g. educational transcripts, professional licenses, digital government IDs, etc.)
  • Storing verifiable credentials at arbitrary identity providers/vaults
  • Requesting verifiable credentials from people and organizations
  • Revoking issued credentials
  • Web Browser APIs for issuing, storing, and consuming credentials
  • User-centric credentials (credential holder is in control of their own credentials)
  • Privacy-enhanced credentials (ensuring privacy when sharing certain credentials)
  • Credential portability (credential holder should be able to easily move credentials from one provider to another)

Dependencies

  • Coordinate with Credentials CG
  • IETF Identity initiative
  • Chairs of security groups in various organizations
  • IMS Global and other education initiatives
  • Verisys and other healthcare initiatives

Phases

Phase I

  • Data format for expressing verifiable attributes

Phase II

  • Browser API for issuing, storing, requesting verifiable attributes
  • HTTP API for issuing, storing, requesting verifiable attributes

Phase III

  • Tokenization of verifiable attributes
  • Self-minted Identifiers (WebDHT)

Phase IV

  • Identity Provider