In a SAML assertion's `<AttributeStatement>`, what do an `<Attribute>`'s `Name` and `NameFormat` tell the service provider?

## The shape `<AttributeStatement>` is one of the statement kinds an assertion may carry, and it is a list. Each entry is an `<Attribute>`: - **`Name`** — required. The identifier of the attribute being asserted. - **`NameFormat`** — optional. How the `Name` is to be interpreted. - **`FriendlyName`** — optional. A human-readable label for the same attribute, meant for people reading the document. - **`<AttributeValue>`** — zero or more children, each one asserted value. At the grain co-operative's intake, one assertion about a driver might assert the haulier's identifier, the driver's licence class, and the list of depots that haulier's contract covers. ## Why `NameFormat` exists at all An attribute name is a string, and two organisations that have never spoken will not agree on strings. `NameFormat` says what kind of naming scheme the string belongs to, so the reader knows whether it is looking at a bare label or at something drawn from a namespace. The format enterprise integrations normally settle on is `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`, where the `Name` is itself a URI. A URI-shaped name is globally unambiguous by construction: two parties can each mint names under a namespace they control and never collide. Other `NameFormat` values are defined, and a deployment that uses one is saying the name means whatever the two parties previously agreed it means. The practical rule that follows is uncomfortable but real: **the meaning of an attribute is an agreement between the two parties, not a property of the document.** SAML gives you a place to put the name, a way to say what kind of name it is, and a place to put values. It does not give you a dictionary. | Part | Required? | What it is for | |---|---|---| | `Name` | yes | which attribute this is | | `NameFormat` | no | how to interpret `Name` | | `FriendlyName` | no | a label for a human reader | | `<AttributeValue>` | zero or more | the asserted values | ## Multi-valued attributes There is no list syntax and no separator convention. A multi-valued attribute is simply one `<Attribute>` with several `<AttributeValue>` children. A reader that takes only the first child silently drops the rest — the classic version of which is a driver whose haulier covers four depots being admitted to one. Equally, an `<Attribute>` with **no** `<AttributeValue>` children is well-formed. It asserts that the attribute is known but carries no value, which is not the same as asserting an empty string. ## `FriendlyName` is not a key `FriendlyName` exists so a person reading the XML can tell what an opaque URI name refers to. It is optional, the issuer chooses it freely, and it may change without the `Name` changing. Anything that selects an attribute by its friendly label rather than its `Name` is matching on a comment. ## Attributes are claims, not grants This is the line worth holding in an interview. An `<AttributeStatement>` records what the issuer asserts about the subject at the moment of issue. It does not decide anything at the reader: 1. The issuer asserts, for example, that this driver's haulier holds contract class B. 2. The reader decides what a contract class B haulier may do at the intake gate. 3. Those are different decisions, made by different parties, and the second one is not in the document. How a reading system turns asserted attributes into its own roles or accounts is its own design problem and lives well outside the assertion grammar. What the grammar owes you is an unambiguous name, a stated interpretation for that name, and the values as the issuer sent them. ## Attributes versus the subject identifier One further distinction catches people out. The `<NameID>` inside `<Subject>` **identifies** the subject; attributes **describe** them. An e-mail address can legitimately appear as both — as a `<NameID>` with the e-mail format, and as an asserted attribute value — and they are not interchangeable. Only the identifier is the thing the statement is about; an attribute value can change next week without the statement being about anyone else. ## What to take away - `Name` says which attribute, `NameFormat` says how to read that name, `<AttributeValue>` carries the values. - The URI name format is how two parties avoid colliding on strings. - Repeated values, not a delimiter, is how multiple values are carried. - `FriendlyName` is for humans; never match on it. - The statement is the issuer's claim, and the reader still owns its own decision.