#idcon vol.29 - #fidcon WebAuthn, Next StageNov Matake
Nov Matake gave a keynote presentation at FIDCon about the next stage of WebAuthn and Passkeys on Apple platforms. He demonstrated syncing Passkeys across devices and using them for autofill on websites. Some challenges remain around credential changes and re-authentication. Syncing Passkeys across different operating systems like Windows, Android, and ChromeOS will also need to be addressed to make the experience better for users.
The document discusses authentication for browser-based and native apps using app-specific, IDP, and third-party backend APIs. It asks questions about obtaining and storing tokens for each API and passing tokens. Answers recommend using OAuth 2.0 for tokens, storing them in keychain/backend server, and passing as bearer tokens. Best practices are proposed like using a mediator flow and letting IDPs handle user interactions.
This document summarizes differences between Sign in with Apple (SIWA) and OpenID Connect (OIDC) and OAuth 2.0 standards. It notes several ways SIWA specifications and behaviors deviate from or violate OIDC standards, including not supporting standard authentication methods, response types, and claims. It also describes SIWA's characteristic identifier design which links multiple apps and services from the same developer together under a single user consent. Developer teams are limited to 10 linked apps/services and must create a new team for additional apps.
This document discusses LINE Corporation's LINE FIDO authentication solution and compares FIDO U2F, FIDO2, and FIDO UAF standards. It outlines the key components of each standard including message formats, protocol specifications, assertion data, and how they ensure interoperability across authenticators. It also mentions potential applications of LINE FIDO in areas like finance and IoT, as well as features like enrollment to address device loss.
The document discusses the W3C Web Authentication standard (also known as FIDO 2.0) for passwordless strong authentication on the web. It provides an overview of the key components and actors in the standard like FIDO authenticators, user agents, relying parties. It then summarizes the basic flows of registration and authentication in 2 phases. During registration, a key pair is generated on the authenticator and the public key is registered with the FIDO server. During authentication, the authenticator performs local authentication using the registered key and sends an assertion to the server for remote authentication.
This document discusses the OPTiM Store, which uses SCIM and OpenID Connect (OIDC) for provisioning and federation between systems like Active Directory and SaaS applications. It outlines the processes for tenant contracting, client registration, and credential exchange to enable synchronization of user identities and attributes from a SaaS application to the OPTiM Store using SCIM, and authentication from the store to SaaS using OIDC single sign-on.
The document discusses standards for identity federation and assertions. It defines four levels of federation assurance (FAL) based on the type of assertion used and how it is presented. FAL1 uses front-channel or back-channel bearer assertions signed by the identity provider. FAL2 adds encryption of assertions to the relying party. FAL3 encrypts assertions to the relying party for both front and back-channel. FAL4 uses holder-of-key assertions, where the assertion contains a public key and proof of possession, signed and encrypted to the relying party. The document provides definitions and discusses security considerations for federation and assertions.
#idcon vol.29 - #fidcon WebAuthn, Next StageNov Matake
Nov Matake gave a keynote presentation at FIDCon about the next stage of WebAuthn and Passkeys on Apple platforms. He demonstrated syncing Passkeys across devices and using them for autofill on websites. Some challenges remain around credential changes and re-authentication. Syncing Passkeys across different operating systems like Windows, Android, and ChromeOS will also need to be addressed to make the experience better for users.
The document discusses authentication for browser-based and native apps using app-specific, IDP, and third-party backend APIs. It asks questions about obtaining and storing tokens for each API and passing tokens. Answers recommend using OAuth 2.0 for tokens, storing them in keychain/backend server, and passing as bearer tokens. Best practices are proposed like using a mediator flow and letting IDPs handle user interactions.
This document summarizes differences between Sign in with Apple (SIWA) and OpenID Connect (OIDC) and OAuth 2.0 standards. It notes several ways SIWA specifications and behaviors deviate from or violate OIDC standards, including not supporting standard authentication methods, response types, and claims. It also describes SIWA's characteristic identifier design which links multiple apps and services from the same developer together under a single user consent. Developer teams are limited to 10 linked apps/services and must create a new team for additional apps.
This document discusses LINE Corporation's LINE FIDO authentication solution and compares FIDO U2F, FIDO2, and FIDO UAF standards. It outlines the key components of each standard including message formats, protocol specifications, assertion data, and how they ensure interoperability across authenticators. It also mentions potential applications of LINE FIDO in areas like finance and IoT, as well as features like enrollment to address device loss.
The document discusses the W3C Web Authentication standard (also known as FIDO 2.0) for passwordless strong authentication on the web. It provides an overview of the key components and actors in the standard like FIDO authenticators, user agents, relying parties. It then summarizes the basic flows of registration and authentication in 2 phases. During registration, a key pair is generated on the authenticator and the public key is registered with the FIDO server. During authentication, the authenticator performs local authentication using the registered key and sends an assertion to the server for remote authentication.
This document discusses the OPTiM Store, which uses SCIM and OpenID Connect (OIDC) for provisioning and federation between systems like Active Directory and SaaS applications. It outlines the processes for tenant contracting, client registration, and credential exchange to enable synchronization of user identities and attributes from a SaaS application to the OPTiM Store using SCIM, and authentication from the store to SaaS using OIDC single sign-on.
The document discusses standards for identity federation and assertions. It defines four levels of federation assurance (FAL) based on the type of assertion used and how it is presented. FAL1 uses front-channel or back-channel bearer assertions signed by the identity provider. FAL2 adds encryption of assertions to the relying party. FAL3 encrypts assertions to the relying party for both front and back-channel. FAL4 uses holder-of-key assertions, where the assertion contains a public key and proof of possession, signed and encrypted to the relying party. The document provides definitions and discusses security considerations for federation and assertions.
SP 800-63-3 is an update to NIST's digital identity guidelines. It introduces a new framework that separates assurance levels into three components: Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL). This provides more flexibility and granularity over the previous version's single Level of Assurance (LOA). The document outlines the recommended requirements and mappings between the new IAL, AAL, FAL framework and the legacy LOA model from SP 800-63-2.
The document discusses OAuth and OpenID Connect protocols. It provides diagrams illustrating the flows of OAuth authorization code grant, implicit grant and hybrid grant flows. It also compares OAuth and OpenID Connect, noting that OpenID Connect builds upon OAuth by adding an identity layer. Key aspects of OpenID Connect like ID tokens and their claims are outlined. Examples of OAuth and OpenID Connect implementations are provided at the end.
This document contains information about Nov Matake, including that he is a security engineer at GREE Inc. and evangelist for the OpenID Foundation. It discusses concepts related to digital identity including entity, identity, authentication, authorization, access control, and identity proofing. It also compares identity providers and relying parties in the context of single sign-on using services like Facebook and Disqus.
The document discusses the FIDO Alliance and its specifications for passwordless and two-factor authentication. It describes the FIDO Alliance's role in defining specifications, issuing vendor codes, and operating a certification program called FIDO Ready. The specifications cover areas like registration, authentication, and key generation in interactions between users' devices, authenticators, clients, and relying parties.
The document is a presentation on OpenID Connect 101 by Nov Matake of OpenID Foundation Japan. It provides an overview of OpenID Connect, including how it uses OAuth 2.0 with an added identity layer, the code flow process, ID tokens and their contents, scopes, discovery, and dynamic client registration. It also discusses password leaks, two-factor authentication, and security best practices.
The document provides an overview of the MIT Kerberos & Internet Trust Consortium (MIT-KIT). It discusses the history and success of Kerberos authentication. The mission of MIT-KIT has expanded to address broader issues in identity, authorization, and privacy on the internet. It envisions an emerging personal data ecosystem where individuals control their own data. MIT-KIT is working on various open source components and standards to help realize this vision, including projects around OpenPDS and implementing the NSTIC Identity Ecosystem Steering Group framework.
This document discusses a self-issued open ID provider that allows identity in devices without central identity provider servers. It generates ID tokens on the device using a self-signed key pair stored securely on the device. The subject ("sub") claim in the ID token is calculated from the public key. This allows each device to have a unique ID token tied to the key pair, with no need for client registration or API access tokens.
The document summarizes several talks from the IIW #16 conference on identity topics. One talk discussed enabling single sign-on across mobile apps by storing an ID token in a shared keychain. Another discussed passing an ID token from a native mobile app to a browser to skip separate login. A third talked presented Google's vision for authentication over the next 5 years, focusing on setup instead of separate sign-ins, reducing bearer tokens, incorporating smarter hardware, and advanced combination authentication techniques. The last summary discussed using OAuth 2.0 and JSON Web Encryption standards for accessing patient health records through a Blue Button API.
The document discusses OAuth 2.0 and OpenID Connect. It provides an overview of OAuth 2.0's authorization code and implicit grant flows for obtaining an access token to access a secured resource. It also mentions OAuth 2.0 is used for access control in APIs and enterprises. Additionally, it states OpenID Connect is based on and extends OAuth 2.0 to provide identity features. Finally, it suggests these protocols are important for applications, access control, identity, social media, clouds, and the growing API economy.
This document discusses the Account Chooser Working Group, an OpenID Foundation initiative to create a standard user interface and user experience for logging into websites and applications. The group aims to develop a central account chooser that allows users to select an identity provider from their browser using local storage. This would provide a better login experience than existing "username/password" or social login options. The document promotes the benefits of implementing the account chooser standard and provides links to related projects and resources.
This document discusses using WebIntents to enable OpenID Connect discovery. WebIntents allows for inter-app communication and discovery on smartphones. The document proposes standardizing intent action values and response formats to enable OpenID Connect providers to be discovered and registration/authorization flows delegated using WebIntents. This avoids the need for direct communication between relying parties and authorization servers.
1. The document discusses OAuth 2.0 and OpenID Connect for API access control and authorization. It provides a brief history of OAuth and describes the core specification and response types.
2. The core specification defines two response types - code and token. The code response type uses authorization codes to obtain access tokens in a two-step process, while the token response type returns access tokens directly.
3. The document also covers token types, notably the bearer token which transmits no signature or secret and is commonly used for API access. It notes that some providers may not follow the latest OAuth draft specifications strictly.
SP 800-63-3 is an update to NIST's digital identity guidelines. It introduces a new framework that separates assurance levels into three components: Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL). This provides more flexibility and granularity over the previous version's single Level of Assurance (LOA). The document outlines the recommended requirements and mappings between the new IAL, AAL, FAL framework and the legacy LOA model from SP 800-63-2.
The document discusses OAuth and OpenID Connect protocols. It provides diagrams illustrating the flows of OAuth authorization code grant, implicit grant and hybrid grant flows. It also compares OAuth and OpenID Connect, noting that OpenID Connect builds upon OAuth by adding an identity layer. Key aspects of OpenID Connect like ID tokens and their claims are outlined. Examples of OAuth and OpenID Connect implementations are provided at the end.
This document contains information about Nov Matake, including that he is a security engineer at GREE Inc. and evangelist for the OpenID Foundation. It discusses concepts related to digital identity including entity, identity, authentication, authorization, access control, and identity proofing. It also compares identity providers and relying parties in the context of single sign-on using services like Facebook and Disqus.
The document discusses the FIDO Alliance and its specifications for passwordless and two-factor authentication. It describes the FIDO Alliance's role in defining specifications, issuing vendor codes, and operating a certification program called FIDO Ready. The specifications cover areas like registration, authentication, and key generation in interactions between users' devices, authenticators, clients, and relying parties.
The document is a presentation on OpenID Connect 101 by Nov Matake of OpenID Foundation Japan. It provides an overview of OpenID Connect, including how it uses OAuth 2.0 with an added identity layer, the code flow process, ID tokens and their contents, scopes, discovery, and dynamic client registration. It also discusses password leaks, two-factor authentication, and security best practices.
The document provides an overview of the MIT Kerberos & Internet Trust Consortium (MIT-KIT). It discusses the history and success of Kerberos authentication. The mission of MIT-KIT has expanded to address broader issues in identity, authorization, and privacy on the internet. It envisions an emerging personal data ecosystem where individuals control their own data. MIT-KIT is working on various open source components and standards to help realize this vision, including projects around OpenPDS and implementing the NSTIC Identity Ecosystem Steering Group framework.
This document discusses a self-issued open ID provider that allows identity in devices without central identity provider servers. It generates ID tokens on the device using a self-signed key pair stored securely on the device. The subject ("sub") claim in the ID token is calculated from the public key. This allows each device to have a unique ID token tied to the key pair, with no need for client registration or API access tokens.
The document summarizes several talks from the IIW #16 conference on identity topics. One talk discussed enabling single sign-on across mobile apps by storing an ID token in a shared keychain. Another discussed passing an ID token from a native mobile app to a browser to skip separate login. A third talked presented Google's vision for authentication over the next 5 years, focusing on setup instead of separate sign-ins, reducing bearer tokens, incorporating smarter hardware, and advanced combination authentication techniques. The last summary discussed using OAuth 2.0 and JSON Web Encryption standards for accessing patient health records through a Blue Button API.
The document discusses OAuth 2.0 and OpenID Connect. It provides an overview of OAuth 2.0's authorization code and implicit grant flows for obtaining an access token to access a secured resource. It also mentions OAuth 2.0 is used for access control in APIs and enterprises. Additionally, it states OpenID Connect is based on and extends OAuth 2.0 to provide identity features. Finally, it suggests these protocols are important for applications, access control, identity, social media, clouds, and the growing API economy.
This document discusses the Account Chooser Working Group, an OpenID Foundation initiative to create a standard user interface and user experience for logging into websites and applications. The group aims to develop a central account chooser that allows users to select an identity provider from their browser using local storage. This would provide a better login experience than existing "username/password" or social login options. The document promotes the benefits of implementing the account chooser standard and provides links to related projects and resources.
This document discusses using WebIntents to enable OpenID Connect discovery. WebIntents allows for inter-app communication and discovery on smartphones. The document proposes standardizing intent action values and response formats to enable OpenID Connect providers to be discovered and registration/authorization flows delegated using WebIntents. This avoids the need for direct communication between relying parties and authorization servers.
1. The document discusses OAuth 2.0 and OpenID Connect for API access control and authorization. It provides a brief history of OAuth and describes the core specification and response types.
2. The core specification defines two response types - code and token. The code response type uses authorization codes to obtain access tokens in a two-step process, while the token response type returns access tokens directly.
3. The document also covers token types, notably the bearer token which transmits no signature or secret and is commonly used for API access. It notes that some providers may not follow the latest OAuth draft specifications strictly.