Skip to content

Conversation

@gladjohn
Copy link
Contributor

Updated the document to reflect changes from 'Short-Lived Credential (SLC)' to 'Certificate' terminology and clarified the handling of certificate revocation scenarios.

Fixes - Spec update

Changes proposed in this request
This pull request updates the documentation for MSI V2 credential revocation, clarifying and expanding the specification to focus on certificate revocation (rather than short-lived credentials) and aligning terminology, flows, error handling, and acceptance tests with current implementation and Azure AD error codes. The changes provide detailed guidance on how MSAL should handle certificate revocation, claims challenges, and telemetry.

Key documentation improvements:

Terminology and Flow Updates:

  • Changed terminology throughout from "Short-Lived Credential (SLC)" to "certificate," clarifying that the revocation and renewal process is certificate-based. Sequence diagrams and flow descriptions are updated for accuracy. [1] [2]

Error Handling and Remediation:

  • Added explicit mapping of AADSTS error codes (1000610–1000614) to certificate/attestation failures and detailed required MSAL remediation steps, including bypassing the cache and minting a new certificate.
  • Provided updated pseudo-code and acceptance tests to reflect these flows, emphasizing auto-remediation and claims challenge handling.

Claims Challenge Handling:

  • Clarified the process for handling claims challenges: when an application receives a 401 with claims, it must pass the claims to MSAL, which then mints a new certificate and retries the token request with the claims.

Acceptance Tests and Telemetry:

  • Revised acceptance test scenarios to match the new flows, including auto-remediation, claims challenges, and telemetry validation.
  • Updated telemetry documentation for MsalMsiCounter to reflect the new tags and expected values for improved diagnostics.

Testing
n/a

Performance impact
n/a

Documentation
n/a

Updated the document to reflect changes from 'Short-Lived Credential (SLC)' to 'Certificate' terminology and clarified the handling of certificate revocation scenarios.
@gladjohn gladjohn requested a review from a team as a code owner September 23, 2025 23:37
Copy link
Member

@bgavrilMS bgavrilMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with comments

Copy link
Member

@bgavrilMS bgavrilMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about telemetry. Maybe start with having those values logged. Let's focus more on server telemetry.

@gladjohn gladjohn requested a review from bgavrilMS September 25, 2025 00:11
participant eSTS

Application ->> MSAL: 1. Request Access Token
MSAL ->> IMDS: 2. Request Certificate
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CSR metadata request is part of the flow. I think you should add it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't see it

MSAL ->> eSTS: 4. Exchange Certificate for Access Token
eSTS -->> MSAL: 5. Response (HTTP 200 / error)

alt Token Revoked / Attestation invalid
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both alts are the same except for 5a and 5b. Do you need to repeat the entire portion of the graph after those sections? Can you just group 5a and 5b together on the graph?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are two different error conditions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain the difference to me. Why aren't the diagrams the same for each condition?

participant Application
participant MSAL
participant IMDS
participant eSTS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a "IMDS/eSTS" section? Why not point towards the already existing "IMDS" and "eSTS" sections?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one is for cert revocation, that MSAL handles internally. The other is for token revocation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't clear on the diagram. Can you use this wording on the diagram?

| **AADSTS1000610–14 Auto-Remediation (Retry Fails)** | Same initial condition as above. New cert minted, retry still fails deterministically (e.g., repeated same code). | Failure surfaced after retry. (`CredentialOutcome=Retry Failed`) |
| **Unspecified Credential Issue** | eSTS returns `invalid_client` without codes. MSAL forces new certificate and retries. | Token succeeds or failure surfaced (assert correct `CredentialOutcome`). |
| **Claims Challenge Path** | Resource 401 with claims; app supplies claims; MSAL re-mints cert (`bypass_cache=true`) and retries with claims. | New token with claims. (`CredentialOutcome=Success`) |
| **IMDS/IssueCredential Failure Path** | `/issuecredential` call fails (network / service / malformed). | Failure returned; no infinite retry. (`CredentialOutcome=Retry Failed` if after a retry attempt) |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

specify which retry policy

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I follow this comment

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mention "retry" several times in this spec. I'm asking you: what retry policy are we using for these retries?

Updated revocation scenarios and clarified certificate request process.
@@ -0,0 +1,196 @@
# Certificate Revocation Specification
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this going to be implemented for preview?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, this is not for preview.

@gladjohn gladjohn requested a review from bgavrilMS October 22, 2025 13:22

This document outlines the design and implementation details for **certificate and token revocation** in MSI V2 scenarios.

In the MSI v2 authentication flow, MSAL first obtains a credential (certificate) from IMDS and uses it to request a token from eSTS. In some cases, eSTS may respond with an error indicating that the certificate/attestation is no longer valid. When this occurs, **MSAL must obtain a new certificate** before retrying the token request with eSTS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSAL first "makes a CSR metadata request"

Copy link
Contributor

@Robbie-Microsoft Robbie-Microsoft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will re-review after you'd had a chance to respond to the comments I just left.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants