A Claims Based Identity System Steve Plank Identity Architect Microsoft UK

topics phishing, phraud identity layer 7 laws human integration consistent experience across contexts Identity metasystem ip rp user identity selector non-disclosure tokens

bad person’s database web server under the control of somebody else ****************

IIS Credentials database FormsAuthentication.SetLoginCookie() Application Error: Cross-domain cookie. A cookie has been received from a security domain other than the one to which this web server is a member. This is a potential security breach. Please consult the application or web server administrator. Custom Solution

Connectivity Naming IP DNS Identity no consistency

user control and consent minimal disclosure for a defined use justifiable parties directional identity pluralism of operators and technologies human integration consistent experience across contexts

Human integration Consistent experience across contexts Planky’s Card Card Collection

Identity Provider First nameLast name Identity Selector Subject 1:1 relationship between cards and identity providers Locally installed software: not under somebody else’s control

Metadata: URI of the Identity Provider Claims you can get from the IP givenname: lastname: user-id: etc: Identity Provider First nameLast name digital signature

Identity Provider digital signature cryptographic binding between the card and the IP

Pluralism of operators and technologies Human integration Consistent experience across contexts There will be many Identity Providers each running its own technology stack OR

Relying Party Identity Provider Subject Identity Metasystem Microsoft Identity MetaSystem WS-* HTML WS-* Web Service WS-* Web Site HTML <wst:Claims wst:Dialect=” <ic:Claim URI=” givenname ”/> <ic:Claim URI=” surname ” <ic:Claim URI=” ”/> <ic:Claim URI=” privatepersonalidentifier ”... <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion" /> <param name="requiredClaims" value=" givenname surname address privatepersonalidentifier " />

Relying Party Identity Selector’s Built-in Identity Provider Subject Identity Metasystem 2 degrees of store protection: System Key Password Key Personal Cards : fixed schema

personal cards managed cards what claims i make about myself what claims another party makes about me fixed schema (protect the users from themselves!) flexible schema

elvis presley only 1 of them is real probably

SECURITY TOKEN Steve Plank Over 18 Over 21 Under 65 image SAML Token XrML License X.509 Certificate Kerberos ticket....others

security token service give it something SECURITY TOKEN Steve Plank Over 18 Over 21 Under 65 image DIFFERENT SECURITY TOKEN Username Password Biometric Signature Certificate web service: STS MEX (Metadata Exchange) endpoint policy how to get tokens token service endpoint responds to RST (Request Security Token) delivers tokens (wrapped in RSTR (RST Response))

relying party identity provider subject click login button policy: uri of ip required claims optional claims token type get policy authenticate RST identity.provider.com requires username and password to validate this request. Enter the information below policy: authn reqs token types... RSTR [ ] s e

relying party identity provider subject real token display token *givenname: Steve *surname: Plank * address: *privatepersonalidentitifer: planky123 Do you want to send this card to: ip.sisa.com ip.sisa.com [ ] token authentication token decryption

... but the IP could tell lies! subject real token display token real token might be opaque how to inform the subject?

Non-disclosure tokens Steve Plank DOB: 17-Jun-59 Authenticity Signature stefan brands credentica u-prove acquired 6th march 2008 privacy

review phishing, phraud identity layer 7 laws human integration consistent experience across contexts Identity metasystem ip rp user identity selector non-disclosure tokens