You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Verifiable credentials are made up of two components, the rules and display definitions. The rules definition determines what the user needs to provide before they receive a verifiable credential. The display definition controls the branding of the credential and styling of the claims. In this guide, we will explain how to modify both files to meet the requirements of your organization.
19
+
Verifiable credentials are made up of two components, the rules and display definitions. The rules definition determines what the user needs to provide before they receive a verifiable credential. The display definition controls the branding of the credential and styling of the claims. In this guide, we'll explain how to modify both files to meet the requirements of your organization.
20
20
21
21
> [!IMPORTANT]
22
-
> Azure Active Directory Verifiable Credentials is currently in public preview.
22
+
> Microsoft Entra Verified ID is currently in public preview.
23
23
> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
24
24
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
25
25
26
26
## Rules definition: Requirements from the user
27
27
28
28
The rules definition is a simple JSON document that describes important properties of verifiable credentials. In particular, it describes how claims are used to populate your verifiable credential.
29
29
30
-
There are currently three input types that are available to configure in the rules definition. These types are used by the verifiable credential issuing service to insert claims into a verifiable credential and attest to that information with your DID. The following are the four types with explanations.
30
+
There are currently four input types that are available to configure in the rules definition. These types are used by the verifiable credential issuing service to insert claims into a verifiable credential and attest to that information with your DID. The following are the four types with explanations.
31
31
32
32
- ID Token
33
33
- ID Token Hint
34
34
- Verifiable credentials via a verifiable presentation.
35
35
- Self-Attested Claims
36
36
37
-
**ID token:** When this option is configured, you will need to provide an Open ID Connect configuration URI and include the claims that should be included in the VC. The user will be prompted to 'Sign in' on the Authenticator app to meet this requirement and add the associated claims from their account.
37
+
**ID token:** When this option is configured, you'll need to provide an Open ID Connect configuration URI and include the claims that should be included in the VC. The user will be prompted to 'Sign in' on the Authenticator app to meet this requirement and add the associated claims from their account.
38
38
39
-
**ID token hint:** The sample App and Tutorial use the ID Token Hint. When this option is configured, the relying party app will need to provide claims that should be included in the VC in the Request Service API issuance request. Where the relying party app gets the claims from is up to the app, but it can come from the current login session, from backend CRM systems or even from self asserted user input.
39
+
**ID token hint:** The sample App and Tutorial use the ID Token Hint. When this option is configured, the relying party app will need to provide claims that should be included in the VC in the Request Service API issuance request. Where the relying party app gets the claims from is up to the app, but it can come from the current sign-in session, from backend CRM systems or even from self asserted user input.
40
40
41
41
**Verifiable credentials:** The end result of an issuance flow is to produce a Verifiable Credential but you may also ask the user to Present a Verifiable Credential in order to issue one. The rules definition is able to take specific claims from the presented Verifiable Credential and include those claims in the newly issued Verifiable Credential from your organization.
42
42
43
43
**Self attested claims:** When this option is selected, the user will be able to directly type information into Authenticator. At this time, strings are the only supported input for self attested claims.
44
44
45
45
46
46
47
-
**Static claims:** Additionally we are able to declare a static claim in the rules definition, however this input doesn't come from the user. The Issuer defines a static claim in the rules definition and would look like any other claim in the Verifiable Credential. Add a credentialSubject after vc.type and declare the attribute and the claim.
47
+
**Static claims:** Additionally we can declare a static claim in the rules definition, however this input doesn't come from the user. The Issuer defines a static claim in the rules definition and would look like any other claim in the Verifiable Credential. Add a credentialSubject after vc.type and declare the attribute and the claim.
48
48
49
49
```json
50
50
"vc": {
@@ -59,7 +59,7 @@ There are currently three input types that are available to configure in the rul
59
59
60
60
## Input type: ID token
61
61
62
-
To get ID Token as input, the rules definition needs to configure the well-known endpoint of the OIDC compatible Identity system. In that system you need to register an application with the correct information from [Issuer service communication examples](issuer-openid.md). Additionally, the client_id needs to be put in the rules definition, as well as a scope parameter needs to be filled in with the correct scopes. For example, Azure Active Directory needs the email scope if you want to return an email claim in the ID token.
62
+
To get ID Token as input, the rules definition needs to configure the well-known endpoint of the OIDC compatible Identity system. In that system you need to register an application with the correct information from [Issuer service communication examples](issuer-openid.md). Additionally, the client_id needs to be put in the rules definition, and a scope parameter needs to be filled in with the correct scopes. For example, Azure Active Directory needs the email scope if you want to return an email claim in the ID token.
63
63
64
64
```json
65
65
{
@@ -94,7 +94,7 @@ To get ID Token as input, the rules definition needs to configure the well-known
94
94
}
95
95
```
96
96
97
-
Please see[idToken attestation](rules-and-display-definitions-model.md#idtokenattestation-type) for reference of properties.
97
+
See[idToken attestation](rules-and-display-definitions-model.md#idtokenattestation-type) for reference of properties.
98
98
99
99
## Input type: ID token hint
100
100
@@ -134,7 +134,7 @@ See [idTokenHint attestation](rules-and-display-definitions-model.md#idtokenhint
134
134
135
135
### vc.type: Choose credential type(s)
136
136
137
-
All verifiable credentials must declare their "type" in their rules definition. The type of a credential distinguishes your verifiable credentials from credentials issued by other organizations and ensures interoperability between issuers and verifiers. To indicate a credential type, you must provide one or more credential types that the credential satisfies. Each type is represented by a unique string - often a URI will be used to ensure global uniqueness. The URI doesn't need to be addressable; it is treated as a string.
137
+
All verifiable credentials must declare their "type" in their rules definition. The type of a credential distinguishes your verifiable credentials from credentials issued by other organizations and ensures interoperability between issuers and verifiers. To indicate a credential type, you must provide one or more credential types that the credential satisfies. Each type is represented by a unique string - often a URI will be used to ensure global uniqueness. The URI doesn't need to be addressable; it's treated as a string.
138
138
139
139
As an example, a diploma credential issued by Contoso University might declare the following types:
140
140
@@ -144,7 +144,7 @@ As an example, a diploma credential issued by Contoso University might declare t
144
144
|`https://schemas.ed.gov/universityDiploma2020`| Declares that diplomas issued by Contoso University contain attributes defined by the United States department of education. |
145
145
|`https://schemas.contoso.edu/diploma2020`| Declares that diplomas issued by Contoso University contain attributes defined by Contoso University. |
146
146
147
-
By declaring all three types, Contoso University's diplomas can be used to satisfy different requests from verifiers. A bank can request a set of `EducationCredential`s from a user, and the diploma can be used to satisfy the request. But the Contoso University Alumni Association can request a credential of type `https://schemas.contoso.edu/diploma2020`, and the diploma will also satisfy the request.
147
+
Contoso declaring three types of diplomas, allows them to issue credentials that satisfy different requests from verifiers. A bank can request a set of `EducationCredential`s from a user, and the diploma can be used to satisfy the request. But the Contoso University Alumni Association can request a credential of type `https://schemas.contoso.edu/diploma2020`, and the diploma will also satisfy the request.
148
148
149
149
To ensure interoperability of your credentials, it's recommended that you work closely with related organizations to define credential types, schemas, and URIs for use in your industry. Many industry bodies provide guidance on the structure of official documents that can be repurposed for defining the contents of verifiable credentials. You should also work closely with the verifiers of your credentials to understand how they intend to request and consume your verifiable credentials.
150
150
@@ -237,7 +237,7 @@ Verifiable credentials issued to users are displayed as cards in Microsoft Authe
Copy file name to clipboardExpand all lines: articles/active-directory/verifiable-credentials/how-to-create-a-free-developer-account.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,19 +12,21 @@ ms.author: barclayn
12
12
# Customer intent: As a developer I am looking to create a developer Azure Active Directory account so I can participate in the Preview with a P2 license.
13
13
---
14
14
15
-
# How to create a free Azure Active Directory developer tenant
15
+
# Microsoft Entra Verified ID developer information
> Azure Active Directory Verifiable Credentials is currently in public preview.
20
+
> Microsoft Entra verified ID is currently in public preview.
21
21
> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
22
22
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
23
23
24
24
> [!NOTE]
25
-
> While in Preview a P2 license is required.
25
+
> The requirement of an Azure AD P2 license was removed in early May 2002. Azure AD Free tier is now supported.
26
26
27
-
There are two easy ways to create a free Azure Active Directory with a P2 trial license so you can install the Verifiable Credential Issuer service and you can test creating and validating Verifiable Credentials:
27
+
## Creating an Azure AD tenant for development
28
+
29
+
There are two easy ways to create a free Azure Active Directory so you can onboard the Verifiable Credential service and test issuing and verifying Verifiable Credentials:
28
30
29
31
-[Join](https://aka.ms/o365devprogram) the free Microsoft 365 Developer Program and get a free sandbox, tools, and other resources like an Azure Active Directory with P2 licenses. Configured Users, Groups, mailboxes etc.
30
32
- Create a new [tenant](../develop/quickstart-create-new-tenant.md) and activate a [free trial](https://azure.microsoft.com/trial/get-started-active-directory/) of Azure AD Premium P1 or P2 in your new tenant.
> Azure Active Directory Verifiable Credentials is currently in public preview.
21
+
> Microsoft Entra Verified ID is currently in public preview.
22
22
> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
23
23
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
24
24
@@ -59,7 +59,7 @@ We follow the [Well-Known DID configuration](https://identity.foundation/.well-k
59
59
]
60
60
```
61
61
62
-
2. The verifiable credential service in Azure AD generates a compliant well-known configuration resource that you can host on your domain. The configuration file includes a self-issued verifiable credential of credentialType 'DomainLinkageCredential' signed with your DID that has an origin of your domain. Here is an example of the config doc that is stored at the root domain URL.
62
+
2. The verifiable credential service in Azure AD generates a compliant well-known configuration resource that you can host on your domain. The configuration file includes a self-issued verifiable credential of credentialType 'DomainLinkageCredential' signed with your DID that has an origin of your domain. Here's an example of the config doc that is stored at the root domain URL.
63
63
64
64
65
65
```json
@@ -112,7 +112,7 @@ It is of high importance that you link your DID to a domain recognizable to the
112
112
## How do you update the linked domain on your DID?
113
113
114
114
1. Navigate to the Verifiable Credentials | Getting Started page.
115
-
1. On the left side of the page select **Domain**.
115
+
1. On the left side of the page, select **Domain**.
116
116
1. In the Domain box, enter your new domain name.
117
117
1. Select **Publish**.
118
118
@@ -158,6 +158,25 @@ If the trust system is ION, once the domain changes are published to ION, the do
158
158
159
159
Congratulations, you now have bootstrapped the web of trust with your DID!
160
160
161
+
## Linked Domain domain made easy for developers
162
+
163
+
The easiest way for a developer to get a domain to use for linked domain is to use Azure Storage's static website feature. You can't control what the domain name will be, other than it will contain your storage account name as part of it's hostname.
164
+
165
+
Follow these steps to quickly set up a domain to use for Linked Domain:
166
+
167
+
1. Create an **Azure Storage account**. During storage account creation, choose StorageV2 (general-purpose v2 account) and Locally redundant storage (LRS).
168
+
1. Go to that Storage Account and select **Static website** in the left hand menu and enable static website. If you can't see the **Static website** menu item, you didn't create a **V2** storage account.
169
+
1. Copy the primary endpoint name that appears after saving. This value is your domain name. It looks something like `https://<your-storageaccountname>.z6.web.core.windows.net/`.
170
+
171
+
When it comes time to upload the `did-configuration.json` file, take the following steps:
172
+
173
+
1. Go to that Storage Account and select **Containers** in the left hand menu. Then select the container named `$web`.
174
+
1. Select **Upload** and select on the folder icon to find your file
175
+
1. Before uploaded, open the **Advanced** section and specify `.well-known` in the **Upload to folder** textbox.
176
+
1. Upload the file.
177
+
178
+
You now have your file publicly available at a URL that looks something like `https://<your-storageaccountname>.z6.web.core.windows.net/.well-known/did-configuration.json`.
179
+
161
180
## Next steps
162
181
163
-
- [How to customize your Azure Active Directory Verifiable Credentials](credential-design.md)
182
+
- [How to customize your Microsoft Entra Verified ID](credential-design.md)
0 commit comments