description: design, recommend, and implement authentication and authorization protocols that rely upon open standards and cryptographic protocols using DIDs and DID Documents.
excerpt: >
The purpose of this working group is to design, recommend and implement authentication and authorization protocols that rely upon open standards and cryptographic protocols using DIDs and DID Documents. Recommendations and development of specifications, protocols, and formats for data structures used for authentication and authorization.
* [DID Authentication Working Group](https://identity.foundation/working-groups/authentication.html) - [GitHub](https://github.com/decentralized-identity/authentication-wg)
> Join this group to contribute to standards and technology that designs and implements authentication protocols that rely upon open standards and cryptographic protocols, including DIDs and DID Documents. This group develops specifications, protocols, and formats for data structures used for authentication.
> The purpose of this working group is to design, recommend and implement authentication and authorization protocols that rely upon open standards and cryptographic protocols using DIDs and DID Documents. Recommendations and development of specifications, protocols, and formats for data structures used for authentication and authorization. The Working Group’s areas of activity may include, but are not limited to, the following:
> - Define the formats and protocols necessary for authentication and authorization using DIDs, DID Documents, and verifiable credentials which we intend to recognize as formally DIF-approved.
> - Develop tools for validation and programmatic interaction for authentication and authorization using DIDs, DID Documents,and verifiable credentials.
> - Create specifications and reference implementations that integrate current authentication and authorization protocols withDIDs, DID Documents, and verifiable credentials.
> - Security analysis and formal DIF-approved reviews of authentication and authorization protocols involving DIDs, DIDDocuments, and verifiable credentials.
* [DIDAuth WG Operating Addendum](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_DIDAuth_WG_Operating_Addendum_v1.pdf)
> We are designing communications protocols specifically for use with the decentralized identifier specification at W3C (https://www.w3.org/TR/did-core/). The DID Core specification and the surrounding family of DID specifications (e.g https://w3c-ccg.github.io/did-resolution/) represent the format for entity identification in our DID Authentication efforts.
## Specs & Projects
### DID Authentication Profile for SIOP
This specification defines the SIOP DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of DID for everyone who wants to have a generic way to integrate SSI wallets into their web applications.
* [Self-Issued OpenID Connect Provider DID Profile v0.1](https://github.com/decentralized-identity/papers/blob/master/did-authn/siop/did-authn-siop-profile.md) - DIF Working Group Draft
> This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.
> Javascript (written in typescript) version of the cryptographic envelope of DIDComm. This library is built for any javascript environment that needs to . It is built on libsodium-js and follows the specs documented in the docs folder.
> There are two layers of messages that combine to enable interoperable self-sovereign agent-to-agent communication. At the highest level are DIDComm Plaintext Messages - messages sent between identities to accomplish some shared goal (e.g., establishing a connection, issuing a verifiable credential, sharing a chat). [DIDComm Plaintext Messages](https://github.com/hyperledger/aries-rfcs/blob/master/features/0044-didcomm-file-and-mime-types/README.md#didcomm-messages-dm) are delivered via the second, lower layer of messaging - [DIDComm Encrypted Envelopes](https://github.com/hyperledger/aries-rfcs/blob/master/features/0044-didcomm-file-and-mime-types/README.md#didcomm-encrypted-envelope-dee). A DIDComm Encrypted Envelope is a wrapper (envelope) around a plaintext message to permit secure sending and routing. A plaintext message going from its sender to its receiver passes through many agents, and an encryption envelope is used for each hop of the journey
* [Introduction to DID Auth for SSI with Markus Sabadello](https://www.slideshare.net/SSIMeetup/introduction-to-did-auth-with-markus-sabadello) 2018-07-04 [SSI-Meetup](https://ssimeetup.org/introduction-did-auth-markus-sabadello-webinar-10/)
> Markus Sabadello, CEO of Danube Tech, will talk about DID Auth, an emerging building block in the SSI ecosystem. Although the technical details of DID Auth are not well-defined at this point, its general concept is clear: With self-sovereign identity infrastructure, the most trivial and straightforward functionality for identity owners should be the ability to authenticate, i.e. to prove control of a DID in some relationship or during a transaction. This could take place using a number of different data formats, protocols, and flows. DID Auth includes the ability to authenticate to web sites and applications, and to establish mutually authenticated communication channels. In this webinar, we will discuss the current state of the DID Auth concept, and how it relates to other efforts such as Verifiable Credentials and agent protocols.
* [DID Auth and the Little I-am-Me](https://medium.com/@markus.sabadello/did-auth-and-the-little-i-am-me-ec14d757ff09) 2018-09-04
> We recently published a report on “DID Auth” ([PDF](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/raw/master/final-documents/did-auth.pdf), [MD](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.md)), which summarizes ideas and possible architectures that allow you to prove that you control a certain Decentralized Identifier (DID). This report originated at the sixth Rebooting-the-Web-of-Trust workshop and is the result of a collaborative effort by several authors and contributors. There is also a webinar.
* [Introduction to DID Auth](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.md)
> The term DID Auth has been used in different ways and is currently not well-defined. We define DID Auth as a ceremony where an identity owner, with the help of various components such as web browsers, mobile devices, and other agents, proves to a relying party that they are in control of a DID. This means demonstrating control of the DID using the mechanism specified in the DID Document's "authentication" object. This could take place using a number of different data formats, protocols, and flows. DID Auth includes the ability to establish mutually authenticated communication channels and to authenticate to web sites and applications. Authorization, Verifiable Credentials, and Capabilities are built on top of DID Auth and are out of scope for this document. This paper gives on overview of the scope of DID Auth, supported protocols and flows, and the use of components of the DID Documents that are relevant to authentication, as well as formats for challenges and responses.
> This is a DID Auth HTTP proxy that uses [HTTP Signatures](https://www.ietf.org/id/draft-cavage-http-signatures-09.txt) based on [Decentralized Identifiers](https://w3c-ccg.github.io/did-spec/) for authenticated HTTP requests.
