From cae8b1d5d2408981641da20657adc8f5cae64243 Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Thu, 18 Apr 2024 04:39:12 +0200 Subject: [PATCH] Rechartering --- 2024/wg-fedid.html | 110 +++++++++++++++++++++++++-------------------- 1 file changed, 61 insertions(+), 49 deletions(-) diff --git a/2024/wg-fedid.html b/2024/wg-fedid.html index c3c233d..c69fcb3 100644 --- a/2024/wg-fedid.html +++ b/2024/wg-fedid.html @@ -75,19 +75,12 @@

Federated Identity Working Group Charter

-

The mission of the Federated Identity Working Group is to - is to develop specifications that allow a website to request an identity credential from a credential container (e.g., a wallet) to authenticate a user and request a set of claims in a way that is compatible with other protocols like OIDC, SAML, and OpenID4VP.

- +

The mission of the Federated Identity Working Group is to develop specifications that allow a website to request an identity credential from an Identity Provider or credential container (i.e., a wallet) to authenticate a user and request a set of claims in a way that is compatible with other protocols like OIDC, SAML, and OpenID4VP.

Join the Federated Identity Working Group.

- -

This updated charter is available - on GitHub. - Feel free to raise issues. -

@@ -96,8 +89,8 @@ Charter Status @@ -105,7 +98,7 @@ Start date @@ -113,7 +106,7 @@ End date @@ -151,29 +144,38 @@

Motivation and Background

- Identity on the Web is critical to online interaction, privacy, and security. W3C has a role in fostering an ecosystem where privacy, security, and user sovereignty are all taken into account. That includes developing new mechanisms for individuals to have the ability to select the identity information, such as assertions, specific credentials, or specific attributes, relevant to a given interaction. These mechanisms must also be viable for the issuers, verifiers, identity providers, and relying parties to exchange information in a secure and privacy-preserving manner. The user agent is the coordinator for these transactions. So, while the request and response protocols are being developed elsewhere (e.g., ISO, IETF, OpenID, and other W3C groups), the web platform layer must also be standardized to provide the privacy and security API framework in a protocol-agnostic fashion in a manner that is compatible with identity request/response protocols like mDoc, Verifiable Credentials, and OpenID4VP. + Identity on the Web is critical to online interaction, privacy, and security. W3C fosters an ecosystem where privacy, security, and user sovereignty are all considered. That includes developing new mechanisms for individuals to have the ability to select the identity information, such as assertions, specific credentials, or specific attributes, relevant to a given interaction. These mechanisms must also be viable for the issuers, verifiers, identity providers, and relying parties to exchange information in a secure and privacy-preserving manner.

- One of the initial hurdles is ensuring support for federated identity while adhering to privacy principles, - despite the deprecation of - third-party cookies, a cornerstone of such operations. + The user agent is the coordinator for these transactions. So, while the request and response protocols are being developed elsewhere (e.g., ISO, IETF, OpenID, and other W3C groups), the web platform layer must also be standardized to provide the privacy and security API framework in a protocol-agnostic and formats-agnostic fashion in a manner that is compatible with identity request/response protocols and different formats.

+

+ The group would like to: +

+

Scope

-

The Working Group will specify new web platform features intended to be implemented in user agents like browsers. The purpose of these features is to support privacy-preserving authentication, authorization flows, and requesting digital credentials without compromising security principles for Identity Providers (IdPs) or Relying Parties (RPs) (in a ‘traditional’ federation model) or Issuers, Verifiers, and Holders (in a digital identity wallet architecture), and User Agents. Here "privacy" minimally refers to the appropriate processing of personal information and preventing third parties from gleaming anything about the end-user's environment (e.g., which wallets are available and their capabilities). The result of this work is the development of new mechanisms that define how information is passed by the browser between the different entities and authentication intermediaries to facilitate federated authentication; these mechanisms are not authentication methods.

- -

If any of the mechanisms developed to support authentication and authorization flows would cause breaking changes for existing protocols, work on that mechanism must include a well-documented transition period.

+

+ The Working Group will specify new web platform features intended to be implemented in user agents like browsers. The purpose of these features is to support privacy-preserving authentication, authorization flows, and requesting federated identities without compromising security principles for Identity Providers (IdPs) or Relying Parties (RPs) (in a ‘traditional’ federation model) or Issuers, Verifiers, and Holders (in a digital identity wallet architecture), and User Agents. Here, “privacy” minimally refers to the appropriate processing of personal information and preventing third parties from gleaming anything about the end-user’s environment (e.g., which wallets are available and their capabilities). This work results in developing new mechanisms that define how information is passed by the browser between the different entities and authentication intermediaries to facilitate federated authentication; these mechanisms are not authentication methods. +

+

+ If any mechanisms developed to support authentication and authorization flows would cause breaking changes for existing protocols, work on that mechanism must include a well-documented transition period. +

Out of Scope

-

The identity space is much larger than that of federated authentication and digital credential wallets. While several topics related to identity may be of interest, they are out of the scope for our work.

+

+ The identity space is much larger than that of federated authentication and digital credential wallets. While several topics related to identity may be of interest, they are out of the scope for our work. +

Specific topics out of scope:

    - -
  • New authentication methods
    • +
  • Designing new authentication methods.
  • Designing individual credential and assertion formats
  • Performing any security or confidence assessment (e.g. checking signatures, audience, encoding, etc) of the

    Draft state: Adopted from the Federated Identity Community Group

    -

    Expected completion: CR in Q1 2025

    +

    Expected completion: CR in Q2 2025

    Login Status API
    @@ -230,21 +232,21 @@

    Draft state: Adopted from the Federated Identity Community Group

    -

    Expected completion: CR in Q1 2025

    +

    Expected completion: CR in Q2 2025

    Tentative Deliverables

    -

    Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Group may also produce Recommendation-track specifications for the following documents:

    +

    Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Group may also produce Recommendation-track specifications for the following document:

    +
    Digital Credentials API

    This specification specifies an API to enable user agents to mediate access to, and presentation of, digital credentials such as a driver's license, government-issued identification card, and/or other types of digital credentials.

    -

    Draft state: Adopted from the +

    Draft state: Draft in the Web Incubator Community Group

    -

    Expected completion: CR in Q4 2025

    - +
@@ -260,8 +262,8 @@

Other non-normative documents may be created such as:

    -
  • Use case and requirement documents;
    • -
  • Implementation report for the specification;
    • +
  • Use case and requirement documents.
    • +
  • Implementation report for the specification.
  • Primer or Best Practice documents to support web developers when designing applications.
  • Harm Model or other documents to identify the impact of the technology (API and also Digital Identities in general) on people and their security and privacy.
    • @@ -272,9 +274,7 @@

    Timeline

    • Q4 2024: FPWD for Federated Credential Management API
      • -
    • Q4 2024: FPWD for Digital Credentials API
    • Q1 2025: CR for Federated Credential Management API
      • -
    • Q4 2025: CR for Digital Credentials API

@@ -292,7 +292,7 @@

Success Criteria

interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or - more implementations interoperating with each other. In order to advance to + more implementations (distinct browser engines) interoperating with each other. In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification.

@@ -310,7 +310,7 @@

Success Criteria

Each specification should contain a Security Considerations section that must include a Threat Model with threats, attacks, mitigations, and residual risks and a Privacy Consideration section as specified in Self-Review Questionnaire: Security and Privacy and RFC 3552, detailing all known security and privacy implications for implementers, Web authors, and end users.

Each specification should contain a section on accessibility that describes the benefits and impacts, including - ways specification features can be used to address them, and + ways specification features can be used to address them and recommendations for maximising accessibility in implementations.

@@ -365,8 +365,11 @@

W3C Groups

ensure that the work of the two groups is not in conflict.
Web Authentication (WebAuthn) Working Group
While we are not developing an authentication mechanism, this work must operate in conjunction with existing authentication mechanisms. The WebAuthn Working Group may provide input and guidance for this requirement.
-
Accessible Platform Architectures (APA) WG
+
Accessible Platform Architectures (APA) Working Group
The APA WG seeks to ensure that accessibility is kept front of mind, as authentication timing and the reliance on short term memory are known and thorny topics for people with disabilities. APA WG can represent these issues that have been raised in the Cognitive Accessibility (COGA) TF, and Accessibility Guidelines (AG) WG. +
Verifiable Credentials Working Group
+
The VC WG is a likely venue for standardization of Data Model for Verifiable Credentials and they are an important stakeholder in the identity space to coordinate with. +
@@ -374,22 +377,31 @@

W3C Groups

External Organizations

IETF
-
A number of IETF working groups, such as oauth, are likely venues for standardization of - protocol components that authentication and authorization features - depend on and research groups are investigating issues that will feed - into the designs this group will consider.
+
To coordinate with the IETF research groups and working groups, such as oauth, for + protocol components that authentication and authorization features + depend on.
OIDF
-
The OpenID Foundation (OIDF) is a likely venue for standardization of - components that certain authorization flows depend on (i.e., OIDC +
To coordinate with the OpenID Foundation (OIDF) for authorization and credentials used in the flows (i.e., OIDC and OpenID4VC specs).
OASIS
-
OASIS is a likely venue for standardization of components that certain - authorization flows depend on (i.e., SAML specs).
+
To coordinate with OASIS for authorization flows used in the flows (i.e., SAML).
REFEDS
-
REFEDS is a likely venue for multi-lateral federation best practices and +
To coordinate with REFEDS for multi-lateral federation best practices and a representative of the complex use cases of the research and education - communities around the world.
+ communities around the world. +
European Telecommunications Standards Institute - Electronic Signatures and Infrastructure Technical Committee
+
+ To coordinate with ETSI for eIDAS, which can use the deliverables of the Group. +
+
National Institute of Standards and Technology, U.S. Department of Commerce
+
+ To coordinate with NIST for their guidelines of Digital Identity and implementations. +
+
ISO/IEC JTC 1 SC17 WG4 and WG10
+
+ To coordinate with ISO for their work on interfaces and protocols for security devices and vehicle driver licence and related digital identities (i.e., mdocs). +
@@ -420,7 +432,7 @@

Participants in the group are required (by the W3C Process) to follow the - W3C Code of Ethics and Professional Conduct.

+ W3C Code of Conduct.

@@ -575,10 +587,10 @@

- See the group status page - and detailed change history. + See the group status page + and detailed change history.
- 28 March 2024 + TBD
- 28 March 2026 + TBD + 2 years
-   + Rechartered - @@ June 2024 + TBD