Standards are theNuts and Bolts of*the Identity Engine* Warning: Some assembly required

Michael B. Jones
Principal, Self-Issued ConsultingStandards are about
making choices

Standards areabout makingchoices

Phillip Hallam-Baker observed
to me at an IETF meeting:Standards make the choicesthat don’t matter.
What an odd thing to say,
but there’s a deep truth there.

Choicesthat don’tmatterIt doesn’t
matter that...

0x0800 is the
EtherType value
for IPv4 packets

6 is the IP
protocol number
for TCP packets

443 is the TCP
port number forHTTPS octetstreams“GET” is theidentifier for anHTTP request
method“HTTP/1.1 200OK” indicates thatan HTTP request
succeeded“application/json” is theContent-Type for
JSON-encoded
messages“{” and “}” delimit
JSON objects“iss” and “sub”
are identifiers in
JSON objects for
JWT claims

65 is the number
for the letter “A” in
ASCII andUnicode

Making choices deeply matters!
Interoperability requires
implementations making
the same choices• Text can be input and displayed
because everyone uses 65 for “A”• HTTPS works because everyoneuses TCP port 443

Standards are where
those choices arewritten down

It’s our job asstandards
professionals to makethose choices

Standards
are the nuts
and bolts ofthe Identity
EngineWhen building machines, we take for
granted having standard parts• Nuts, bolts, wires, light bulbs, and countlessother parts• All conforming to applicable standards• Enables a marketplace of interoperable parts
from multiple suppliers• Without these standards, every part would becustom machined

The same is true of the identity and security standards we use to build the Identity Engine

Some
AssemblyRequired

Our identity and security
standards vary wildly in thedegree to which they makechoices• Some define one way to do things,
resulting in interoperability• Others leave critical choices unmade,passing them on to implementers• Your mileage may vary!

Naming
Names &Taking
Prisoners

Next, I’ll critique existing andemerging identity and security
standards through this lensI’ll give each my personal gradeon choices madeABESTBCDFWORST

X.509 is a decades-old widely-deployed
digital certificate format

There are interoperable profiles of X.509• Especially for TLS certificates

X.509

But choices have evolved over time
• Domain names used to be in the commonName
field• Now in Subject Alternate Name (SAN) field

Multiple revocation mechanisms• Certificate Revocation Lists (CRLs)• Online Certificate Status Protocol (OCSP)SAML is the original single-sign-on protocol
standard
There are interoperable SAML 2.0 ecosystems

SAML 2.0• Each made many profiling choices to achieve thisSAML NameID contents vary

• Can be transient, persistent, unspecified, emailAddress,
X509SubjectName, WindowsQualifiedDomainName, Kerberos,
EntityMultiple protocol flows• Browser profile, Artifact Binding, Enhanced Client Proxy (ECP)

Multiple logout mechanisms
Dependent upon brittle XML Canonicalization

OAuth 2.0 enables limited access toresources in controlled fashion
OAuth 2.0 is not interoperable without a profile

OAuth 2.0:
RFC 6749 &RFC 6750

Different response_type values with different
security properties• code, token, and others defined by extensions

scope values completely unspecified
Multiple token_type possibilities• Bearer and othersRFC 6750 defines three ways to pass accesstoken• Header, Body Parameter, Query Parameters

OpenID Connect is a widely-used sign-in
standardOpenID
Connect

Interoperable ecosystem enabled because ofchoices made• For instance, chose exact redirect_uri matching• Interoperability evidence: 754 OpenID Connect certifications
to date!

Building on OAuth 2.0 introduced morechoices than ideal• Six response types, each with different security properties

Three IdP-initiated logout mechanisms• Two using browser features, one using server-to-servercommunication

JWS is a widely-used JSON-based digital
signature format
Compact serialization is the most used

JSON Web
Signature(JWS)

JSON serialization was added late to satisfy
vocal constituency• JSON serialization also includes unprotected headers

Other than serialization choice, mostchoices made by spec“alg” choice is needed to support cryptographicagility

JWT is a widely-used JSON-based digitaltoken format in which secured claims are
made about a subject

JSON Web
Token(JWT)

Requires JWS compact serialization be usedYes, all claims are optional at the JWT level• Leaves room for profiles such as ID Token to specify
claims usedJWT BCP [RFC 8725] further tightens
choices madeMany interoperable implementations indifferent languages

COSE is a widely-used binary signingand encryption format

CBOR Object
Signing andEncryption(COSE)COSE makes similar degree of choices
as JOSE (JWS, etc.)
Includes both protected and unprotected
headers
Has some bells and whistles that JOSE
doesn’t• Such as countersignatures

Enough choices made to enableinteroperability

CWT is a widely-used binary digitaltoken format in which secured claims
are made about a subject

CBOR Web
Token (CWT)CWT makes largely parallel choices toJWT
But does not narrow COSE features
used (unlike JWT)
• Does not mandate using COSE_Sign1 over
COSE_Sign• Does not mandate that only protected headers
be usedSame claims extensibility model as JWTWebCrypto defines Web API for inbrowser cryptographic operations
Only one way to perform any operation

WebCrypto

Limited number of key formats using
existing standards• enum KeyFormat { "raw", "spki","pkcs8", "jwk" };Intentionally excludes functionality somewanted• Use of platform keys
• Has led to non-standard extensions

WebAuthn/FIDO 2 is deployedunphishable login infrastructure
supported by all modern browsers

WebAuthn/
FIDO 2Evolved from and replaces U2F/CTAP 1• Resulted in multiple signature formats, someX.509-based, some bareMultiple and evolving attestation formats
Numerous extensions with varying
degree of implementation• Which extensions will be ubiquitously supported
is still TBD

VCs represent cryptographically secured
claims by an issuer about a subject
VC 1.0, 1.1, and 2.0 made different choices

W3C
VerifiableCredentials• VC 2.0 not backwards compatible with previousversions• Two ways of signing VCs, each withsub-variants• VC-JOSE-COSE supports JWS, COSE, and SDJWT signatures over JSON-LD payload• VC-DATA-INTEGRITY canonicalizes JSON-LD
payload, converts it to RDF N-Quads, and signs
over the RDF (or can use JCS [RFC 8785])

DIDs are a framework for identifiers
about subjects not dependent uponcentral authorities

Decentralized
Identifiers(DIDs)

Each kind of DID has its own DID method andalgorithms
DID spec defines operations that DID Methods
must implement
As of this writing, there are 193 registered
DID Methods!
• None are mandatory to implement, giving nointerop guarantee• DID Methods are out of scope for the newly
rechartered DID WG!

Defines multiplicity of encodings for binary
dataMultiformats

The Multibase spec defines 23 equivalent and noninteroperable representations for the same data!
• base64*, base58*, base36*, base32* , hex*, decimal,base8, base2, binary• Interop requires either implementing them all orprofiles choosing someMultiformats institutionalize the failure to make achoice!
Warning: Multiformats are used by VC-DATAINTEGRITY and DIDs
So bad, I wrote “Multiformats Considered Harmful”
post!

Closing Remarks
on Choices

Enablinglayeredprotocols
is a choice• Ethernet packet types are identified by
EtherType• IPv4 protocols are identified by protocol number• TCP protocols are identified by port number• JWT types are identified by the “typ” header
parameter• These all enable higher-level protocols to belayered over them• Sometimes it’s necessary for choices
to change over time

Planning forevolution
is a choice• Particularly as the security threat
landscape evolves• For instance, enabling cryptographic
agility is a must
• Which algorithms are secure changes
over time• Only supporting a fixed algorithm
would be a bad choice!

All the specifications I’ve discussed
have extensibility points• Extensibility enables new features to be added• Such as adding DPoP to OAuth 2.0

Extensibility
is a choice• Extensibility enables new layered applications
and protocols• Such as adding an ID Token to OAuth 2.0 for
OpenID Connect

Use extension methods that don’t breakexisting deployments• For instance, the “If you don’t understand it,
you MUST ignore it” logic for OAuth 2.0
request parameters and JWT claims has
served us well

Standards are about
making choices,
so make good ones!

Thank you
This presentation andmore are available at:https://self-issued.info