What are the main parts of a SAML 2.0 assertion, and which part names the person it describes?

## What the document is A SAML 2.0 assertion is a single XML element, `<saml:Assertion>`, in the namespace `urn:oasis:names:tc:SAML:2.0:assertion`. In it, one party states — at one moment, about one subject — a fixed set of things. It is not a session, not a key, and not an OAuth2 access token. It is a **dated statement with a bounded life, addressed to a named reader**. The element itself carries three attributes: - `ID` — a unique identifier for this assertion, the handle everything else refers to it by. - `IssueInstant` — a UTC instant saying when it was created. - `Version` — `2.0`. Picture a grain co-operative's intake office. A haulier's driver rolls onto the weighbridge, and the intake system has to know, from a statement issued minutes earlier somewhere else, who is driving and which haulier they represent. Every part below is a part of that statement. ## Who is speaking, and about whom `<Issuer>` names the party that made the statement: an `entityID` URI naming an organisation's identity provider, never a person. `<Subject>` names who the statement is about, and it does two jobs. 1. **Identify.** A `<NameID>` — or an `<EncryptedID>` where the identifier itself is hidden from anything between the two parties — whose `Format` attribute says what kind of identifier it is. `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` is a stable pseudonym for this subject between this pair of parties; `urn:oasis:names:tc:SAML:2.0:nameid-format:transient` is good for this login only; `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` is an address. 2. **Say how the holder may be confirmed as that subject.** `<SubjectConfirmation>` with `Method` set to `urn:oasis:names:tc:SAML:2.0:cm:bearer` in browser single sign-on, meaning whoever delivers this document is treated as the subject. Its `<SubjectConfirmationData>` carries `Recipient` (the endpoint this copy was meant for), `NotOnOrAfter` (how long delivery may take), `InResponseTo` and optionally `Address`. The other defined method, `urn:oasis:names:tc:SAML:2.0:cm:holder-of-key`, instead requires the presenter to prove possession of a key. ## What is claimed The statements carry the content: - `<AuthnStatement>` — this subject authenticated to the issuer. `AuthnInstant` says when, `SessionIndex` names the issuer's session, `SessionNotOnOrAfter` bounds that session, and `<AuthnContextClassRef>` says by what class of method. - `<AttributeStatement>` — a list of `<Attribute>` elements, each with a `Name` and usually a `NameFormat`, each holding `<AttributeValue>` children: the haulier's identifier, the driver's licence class, the depots they may enter. Statements are optional in the core grammar; an assertion may carry none. The Web Browser SSO profile is what requires an `<AuthnStatement>`, and attributes travel only where the two parties agreed in advance which ones and under which `Name` values. ## What bounds it `<Conditions>` is the fence around the statement: - `NotBefore` and `NotOnOrAfter` — the window inside which the statement may be relied on at all. - `<AudienceRestriction>` holding `<Audience>` values — the parties it is addressed to, as `entityID` URIs. - `<OneTimeUse>` — a signal that the relying party must not keep it around in a form that could be used again. - `<ProxyRestriction>` — a limit on further assertions issued onward from this one. `<Advice>` may carry supporting material the relying party is free to ignore. | Element | Names or bounds | Value shape | |---|---|---| | `<Issuer>` | who made the statement | an `entityID` URI | | `<NameID>` | who the statement is about | an identifier plus a `Format` | | `<SubjectConfirmationData>` | where and how long this copy may be delivered | `Recipient`, `NotOnOrAfter`, `InResponseTo` | | `<Conditions>` | when, and to whom, it may be relied on | two instants and `<Audience>` URIs | | `<AuthnStatement>` | that the subject authenticated | `AuthnInstant`, `SessionIndex` | | `<AttributeStatement>` | what else is claimed | `<Attribute>` and `<AttributeValue>` | ## Order matters when you read one The children appear in a fixed order: `<Issuer>` first, then a signature if one is present, then `<Subject>`, `<Conditions>`, `<Advice>`, then the statements. How the assertion is signed or encrypted, and how that is checked, is a separate subject from the grammar described here. ## What it is not - **Not a session.** The assertion is a statement delivered once. Any session the intake system then keeps is its own, with its own lifetime. - **Not a permission list.** The attributes are the issuer's claims about the driver; whether that driver may book an intake slot is the intake system's decision. - **Not open-ended.** Without the `<Conditions>` window and `<AudienceRestriction>`, the same document read later or elsewhere still parses — which is exactly why those elements exist.