This document summarizes a presentation about OpenID Connect. OpenID Connect is an identity layer on top of the OAuth 2.0 protocol that allows clients to verify the identity of the user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the user. It defines core functionality for modern identity frameworks by standardizing how clients and servers discover and use identity data exposed by identity providers and how clients can verify that identity data. The presenter discusses how OpenID Connect provides a simple yet powerful way to authenticate users and share attributes about them between websites and applications in an interoperable manner.
This document discusses authentication and authorization frameworks like OAuth and OpenID Connect. It provides an overview of key concepts like authentication, authorization, roles in OAuth like resource owner, client, authorization server and resource server. It explains the authorization code grant flow in OAuth and how OpenID Connect builds upon OAuth to provide identity features. It also compares OpenID Connect to SAML and discusses Microsoft and TechCello implementations of these specifications.
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf.
This slide deck gives an introduction to OAuth 2.0, starting with some concepts, explaining the flow plus a few hints. The reminder of the slides are about implementing an OAuth 2.0 server using the Apache Amber library (renamed to Apache Oltu lately). My impression is that many developers shy away as soon as they hear "security" and so I did not only want to talk about the concepts of OAuth 2.0 but also wanted to show how easily you can implement an OAuth 2.0 server ... hope it reduces the fear of contact a bit ... ;-)
The document provides an overview of the history and development of OAuth standards for authorization. It describes some of the issues with early implementations that prompted the creation of OAuth 1.0, including services storing user passwords and lack of ability to revoke access. OAuth 1.0 introduced signatures to address these issues. OAuth 2.0 replaced signatures with HTTPS and defines common flows for different use cases, including authorization code, implicit, password, and client credentials grants.
OAuth and OpenID Connect are the two most important security specs that API providers need to be aware of. In this session, Travis Spencer, CEO of Curity, will cram in as much about these two protocols as will fit into 20 minutes.
This document discusses authentication and authorization frameworks like OAuth and OpenID Connect. It provides an overview of key concepts like authentication, authorization, roles in OAuth like resource owner, client, authorization server and resource server. It explains the authorization code grant flow in OAuth and how OpenID Connect builds upon OAuth to provide identity features. It also compares OpenID Connect to SAML and discusses Microsoft and TechCello implementations of these specifications.
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf.
This slide deck gives an introduction to OAuth 2.0, starting with some concepts, explaining the flow plus a few hints. The reminder of the slides are about implementing an OAuth 2.0 server using the Apache Amber library (renamed to Apache Oltu lately). My impression is that many developers shy away as soon as they hear "security" and so I did not only want to talk about the concepts of OAuth 2.0 but also wanted to show how easily you can implement an OAuth 2.0 server ... hope it reduces the fear of contact a bit ... ;-)
The document provides an overview of the history and development of OAuth standards for authorization. It describes some of the issues with early implementations that prompted the creation of OAuth 1.0, including services storing user passwords and lack of ability to revoke access. OAuth 1.0 introduced signatures to address these issues. OAuth 2.0 replaced signatures with HTTPS and defines common flows for different use cases, including authorization code, implicit, password, and client credentials grants.
OAuth and OpenID Connect are the two most important security specs that API providers need to be aware of. In this session, Travis Spencer, CEO of Curity, will cram in as much about these two protocols as will fit into 20 minutes.
This document provides guidelines for securing managed APIs. It discusses defining an API's audience and whether they are direct users or relying parties. It also covers bootstrapping trust either directly through user credentials or brokerd through a third party. The document then discusses various OAuth 2.0 grant types and federated access scenarios. It emphasizes using TLS, strong credentials, short-lived tokens, and access control to secure APIs and their communication.
The document discusses API security patterns and practices. It covers topics like API gateways, authentication methods like basic authentication and OAuth 2.0, authorization with XACML policies, and securing APIs through measures like TLS, JWTs, and throttling to ensure authentication, authorization, confidentiality, integrity, non-repudiation, and availability. Key points covered include the gateway pattern, direct vs brokered authentication, JSON web tokens for self-contained access tokens, and combining OAuth and XACML for fine-grained access control.
An introduction to OAuth2 and OpenID Connect intended for a technical audience. This covers terminology, core concepts, and all the core grants/flows for OAuth2 and OpenID Connect
It seems that OAuth 2.0 is everywhere these days. Whether you are building a hot new single page web application (SPA), a native mobile experience, or just trying to integrate with the API economy, you can't go far without running into the popular authorization framework for REST/APIs and social authentication.
During Oktane15 (https://www.okta.com/oktane15/), Karl McGuinness, our Senior Director of Identity, demystified the powerful, yet often misunderstood, world of OAuth 2.0 and shared details on Okta’s growing support for OpenID Connect.
This document provides an introduction and overview of OAuth 2.0. It discusses the key components and actors in the OAuth framework, including clients, protected resources, resource owners, and authorization servers. It describes the major steps of an OAuth transaction, issuing and using tokens. Specifically, it outlines the authorization code grant flow, how clients request and receive access tokens from authorization servers to access protected resources on behalf of resource owners. It also defines common OAuth concepts like scopes, refresh tokens, and authorization grants.
How to integrate the complex use cases in the hyper-connected world with millions of devices and services.
Bhavna Bhatnagar (VigourSoft Technical Advisor and Industry expert) talks about SAML, OAuth, OpenID and what you need to make your place in the complex scenario this presents
OAuth 2 is an authorization framework that allows applications to access user data and perform actions on their behalf. It defines flows for applications to request access, and provides short-lived credentials in response. The main roles in OAuth are the resource owner (user), client (application), resource server (API), and authorization server (issues tokens). Common grant types include authorization code, implicit, and client credentials flows. Tokens returned include access and refresh tokens, and OpenID Connect adds optional ID tokens containing user information.
SAML, OAuth 2.0, and OpenID Connect are the three most common authentication protocols. SAML provides authentication and authorization assertions while OAuth 2.0 focuses on authorization. OpenID Connect builds on OAuth 2.0 by adding authentication features and using claims to provide user information. It has a lower implementation barrier than SAML and is well-suited for mobile and API use cases. The document compares the protocols and their applications, security considerations, and history of adoption.
This 20-minute presentation introduces OAuth through defining it, explaining why it is useful, providing background information, defining key terminology, outlining the workflow, and including a live example. It defines OAuth as a method for users to grant third-party access to their resources without sharing passwords and to grant limited access. It highlights issues with traditional client-server authentication and how OAuth addresses them. The presentation then covers OAuth background, terminology like consumer and service provider, the redirection-based authorization workflow, and concludes with a live example and references for further information.
This document provides an introduction to Security Assertion Markup Language (SAML) 2.0, including:
- SAML is an XML-based standard for exchanging authentication and authorization data between parties like an identity provider and service provider.
- It defines roles like identity providers, service providers, and users.
- SAML supports single sign-on, attribute sharing, identity federation, and other use cases through protocols, bindings, and profiles.
- Liferay supports acting as an identity provider or service provider using SAML through an enterprise edition plugin, allowing configuration as an IdP or SP through properties and metadata files.
- The presentation demonstrates SAML single sign-on flows and configurations using examples
APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson...apidays
APIsecure 2023 - The world's first and only API security conference
March 14 & 15, 2023
OAuth, OIDC and protecting third-party credentials
Edmund Olson-Morgan, Core API and Innovation Lead at Marsh McLennan
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Building an enterprise level single sign-on application with the help of keycloak (Open Source Identity and Access Management).
And understanding the way to secure your application; frontend & backend API’s. Managing user federation with minimum configuration.
OpenAPI 3.0, And What It Means for the Future of SwaggerSmartBear
OpenAPI 3.0, which is based on the original Swagger 2.0 specification, is meant to provide a standard format to unify how an industry defines and describes RESTful APIs.
The release of OAS 3.0 marks a significant milestone in the growth of the API economy — bringing together collaborators from across industries, to evolve the specification to meet the needs of API developers and consumers across the world in an open and transparent manner.
We hosted a free Swagger training: OpenAPI 3.0, And What it Means for the Future of Swagger. More than 2,000 people signed up to learn more about the new specification, and to find out about what’s coming next for Swagger and SwaggerHub!
You can watch the full recording of the presentation here: https://swaggerhub.com/blog/api-resources/openapi-3-0-video-tutorial/
This document provides an overview of Kong, an open-source API gateway. It discusses that Kong is a cloud-native, scalable middleware between clients and APIs, and supports features like authentication, security, traffic control, and analytics. The document also summarizes the Community and Enterprise editions of Kong, including that the Enterprise edition provides additional capabilities like an admin GUI, API analytics, and support. It concludes with an example of using Kong to expose an API and discusses benefits and concerns of Kong.
The slides from the talk I gave in Java.IL's Apr 2019 session.
These slides describe Keycloak, OAuth 2.0, OpenID and SparkBeyond's integration with Keycloak
OpenID Connect is a simple identity layer that allows clients like mobile or web apps to verify user identities based on an authentication performed by an authorization server, as well as obtain basic profile information about users. It is built on OAuth 2.0 and defined by the OpenID Foundation. The specification defines core features as well as optional discovery, dynamic registration, session management, and OAuth 2.0 response types. Major companies like Google, Salesforce, and Microsoft have implemented or are deploying OpenID Connect to provide single sign-on for web and mobile clients.
[APIdays INTERFACE 2021] The Evolution of API Security for Client-side Applic...WSO2
Client-side applications are becoming an increasingly popular technology to build applications owing to the advanced user experience that they provide consumers. Authentication and API authorization for these applications are also becoming equally popular topics that many developers have a hard time getting their heads around.
Check these slides, where Johann Nallathamby, Head of Solutions Architecture for IAM at WSO2, will attempt to demystify some complexities and misconceptions surrounding this topic and help you better understand the most important features to consider when choosing an authentication and API authorization solution for client-side applications.
These slides will review:
- The broader classification of client-side applications and their legacy and more recent authentication and API authorization patterns
- Sender-constrained token patterns
- Solution patterns being employed to improve user experience in client-side applications
Security for oauth 2.0 - @topavankumarjPavan Kumar J
The document provides an overview of OAuth 2.0 authorization framework and discusses common security issues. It begins with introducing the speaker and their background in security. The main topics covered include the history and core elements of OAuth, common grant types and flows, and vulnerabilities like insecure storage of secrets, CSRF attacks during authorization, scope permission issues, and account takeover risks. Best practices for clients and authorization servers to mitigate these threats are also outlined.
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.
This document discusses OpenID, an open standard for decentralized authentication on the web. It notes some problems with traditional username and password systems like passwords being hard to manage and user databases being vulnerable to theft. OpenID provides a solution by allowing users to authenticate using a URL of their choice, like a personal domain name, rather than having separate usernames and passwords for each site. When authenticating with a new site, OpenID verifies the user's identity through their OpenID provider rather than the site directly. The document provides examples of how OpenID works and can be implemented using libraries like Net::OpenID::Consumer in Perl. It also addresses questions like how to choose an OpenID provider and maintain multiple personas.
This document provides guidelines for securing managed APIs. It discusses defining an API's audience and whether they are direct users or relying parties. It also covers bootstrapping trust either directly through user credentials or brokerd through a third party. The document then discusses various OAuth 2.0 grant types and federated access scenarios. It emphasizes using TLS, strong credentials, short-lived tokens, and access control to secure APIs and their communication.
The document discusses API security patterns and practices. It covers topics like API gateways, authentication methods like basic authentication and OAuth 2.0, authorization with XACML policies, and securing APIs through measures like TLS, JWTs, and throttling to ensure authentication, authorization, confidentiality, integrity, non-repudiation, and availability. Key points covered include the gateway pattern, direct vs brokered authentication, JSON web tokens for self-contained access tokens, and combining OAuth and XACML for fine-grained access control.
An introduction to OAuth2 and OpenID Connect intended for a technical audience. This covers terminology, core concepts, and all the core grants/flows for OAuth2 and OpenID Connect
It seems that OAuth 2.0 is everywhere these days. Whether you are building a hot new single page web application (SPA), a native mobile experience, or just trying to integrate with the API economy, you can't go far without running into the popular authorization framework for REST/APIs and social authentication.
During Oktane15 (https://www.okta.com/oktane15/), Karl McGuinness, our Senior Director of Identity, demystified the powerful, yet often misunderstood, world of OAuth 2.0 and shared details on Okta’s growing support for OpenID Connect.
This document provides an introduction and overview of OAuth 2.0. It discusses the key components and actors in the OAuth framework, including clients, protected resources, resource owners, and authorization servers. It describes the major steps of an OAuth transaction, issuing and using tokens. Specifically, it outlines the authorization code grant flow, how clients request and receive access tokens from authorization servers to access protected resources on behalf of resource owners. It also defines common OAuth concepts like scopes, refresh tokens, and authorization grants.
How to integrate the complex use cases in the hyper-connected world with millions of devices and services.
Bhavna Bhatnagar (VigourSoft Technical Advisor and Industry expert) talks about SAML, OAuth, OpenID and what you need to make your place in the complex scenario this presents
OAuth 2 is an authorization framework that allows applications to access user data and perform actions on their behalf. It defines flows for applications to request access, and provides short-lived credentials in response. The main roles in OAuth are the resource owner (user), client (application), resource server (API), and authorization server (issues tokens). Common grant types include authorization code, implicit, and client credentials flows. Tokens returned include access and refresh tokens, and OpenID Connect adds optional ID tokens containing user information.
SAML, OAuth 2.0, and OpenID Connect are the three most common authentication protocols. SAML provides authentication and authorization assertions while OAuth 2.0 focuses on authorization. OpenID Connect builds on OAuth 2.0 by adding authentication features and using claims to provide user information. It has a lower implementation barrier than SAML and is well-suited for mobile and API use cases. The document compares the protocols and their applications, security considerations, and history of adoption.
This 20-minute presentation introduces OAuth through defining it, explaining why it is useful, providing background information, defining key terminology, outlining the workflow, and including a live example. It defines OAuth as a method for users to grant third-party access to their resources without sharing passwords and to grant limited access. It highlights issues with traditional client-server authentication and how OAuth addresses them. The presentation then covers OAuth background, terminology like consumer and service provider, the redirection-based authorization workflow, and concludes with a live example and references for further information.
This document provides an introduction to Security Assertion Markup Language (SAML) 2.0, including:
- SAML is an XML-based standard for exchanging authentication and authorization data between parties like an identity provider and service provider.
- It defines roles like identity providers, service providers, and users.
- SAML supports single sign-on, attribute sharing, identity federation, and other use cases through protocols, bindings, and profiles.
- Liferay supports acting as an identity provider or service provider using SAML through an enterprise edition plugin, allowing configuration as an IdP or SP through properties and metadata files.
- The presentation demonstrates SAML single sign-on flows and configurations using examples
APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson...apidays
APIsecure 2023 - The world's first and only API security conference
March 14 & 15, 2023
OAuth, OIDC and protecting third-party credentials
Edmund Olson-Morgan, Core API and Innovation Lead at Marsh McLennan
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Building an enterprise level single sign-on application with the help of keycloak (Open Source Identity and Access Management).
And understanding the way to secure your application; frontend & backend API’s. Managing user federation with minimum configuration.
OpenAPI 3.0, And What It Means for the Future of SwaggerSmartBear
OpenAPI 3.0, which is based on the original Swagger 2.0 specification, is meant to provide a standard format to unify how an industry defines and describes RESTful APIs.
The release of OAS 3.0 marks a significant milestone in the growth of the API economy — bringing together collaborators from across industries, to evolve the specification to meet the needs of API developers and consumers across the world in an open and transparent manner.
We hosted a free Swagger training: OpenAPI 3.0, And What it Means for the Future of Swagger. More than 2,000 people signed up to learn more about the new specification, and to find out about what’s coming next for Swagger and SwaggerHub!
You can watch the full recording of the presentation here: https://swaggerhub.com/blog/api-resources/openapi-3-0-video-tutorial/
This document provides an overview of Kong, an open-source API gateway. It discusses that Kong is a cloud-native, scalable middleware between clients and APIs, and supports features like authentication, security, traffic control, and analytics. The document also summarizes the Community and Enterprise editions of Kong, including that the Enterprise edition provides additional capabilities like an admin GUI, API analytics, and support. It concludes with an example of using Kong to expose an API and discusses benefits and concerns of Kong.
The slides from the talk I gave in Java.IL's Apr 2019 session.
These slides describe Keycloak, OAuth 2.0, OpenID and SparkBeyond's integration with Keycloak
OpenID Connect is a simple identity layer that allows clients like mobile or web apps to verify user identities based on an authentication performed by an authorization server, as well as obtain basic profile information about users. It is built on OAuth 2.0 and defined by the OpenID Foundation. The specification defines core features as well as optional discovery, dynamic registration, session management, and OAuth 2.0 response types. Major companies like Google, Salesforce, and Microsoft have implemented or are deploying OpenID Connect to provide single sign-on for web and mobile clients.
[APIdays INTERFACE 2021] The Evolution of API Security for Client-side Applic...WSO2
Client-side applications are becoming an increasingly popular technology to build applications owing to the advanced user experience that they provide consumers. Authentication and API authorization for these applications are also becoming equally popular topics that many developers have a hard time getting their heads around.
Check these slides, where Johann Nallathamby, Head of Solutions Architecture for IAM at WSO2, will attempt to demystify some complexities and misconceptions surrounding this topic and help you better understand the most important features to consider when choosing an authentication and API authorization solution for client-side applications.
These slides will review:
- The broader classification of client-side applications and their legacy and more recent authentication and API authorization patterns
- Sender-constrained token patterns
- Solution patterns being employed to improve user experience in client-side applications
Security for oauth 2.0 - @topavankumarjPavan Kumar J
The document provides an overview of OAuth 2.0 authorization framework and discusses common security issues. It begins with introducing the speaker and their background in security. The main topics covered include the history and core elements of OAuth, common grant types and flows, and vulnerabilities like insecure storage of secrets, CSRF attacks during authorization, scope permission issues, and account takeover risks. Best practices for clients and authorization servers to mitigate these threats are also outlined.
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.
This document discusses OpenID, an open standard for decentralized authentication on the web. It notes some problems with traditional username and password systems like passwords being hard to manage and user databases being vulnerable to theft. OpenID provides a solution by allowing users to authenticate using a URL of their choice, like a personal domain name, rather than having separate usernames and passwords for each site. When authenticating with a new site, OpenID verifies the user's identity through their OpenID provider rather than the site directly. The document provides examples of how OpenID works and can be implemented using libraries like Net::OpenID::Consumer in Perl. It also addresses questions like how to choose an OpenID provider and maintain multiple personas.
Securing RESTful APIs using OAuth 2 and OpenID ConnectJonathan LeBlanc
Constructing a successful and simple API is the lifeblood of your developer community, and REST is a simple standard through which this can be accomplished. As we construct our API and need to secure the system to authenticate and track applications making requests, the open standard of OAuth 2 provides us with a secure and open source method of doing just this. In this talk, we will explore REST and OAuth 2 as standards for building out a secure API infrastructure, exploring many of the architectural decisions that PayPal took in choosing variations in the REST standard and specific implementations of OAuth 2.
Best Practices You Must Apply to Secure Your APIs - Scott Morrison, SVP & Dis...CA API Management
The document discusses best practices for securing APIs and identifies three key areas: parameterization, identity, and cryptography. It notes that APIs have a larger attack surface than traditional web apps due to more direct parameterization. It recommends rigorous input and output validation, schema validation, and constraining HTTP methods and URIs. For identity, it advises using real security tokens like OAuth instead of API keys alone. It also stresses the importance of proper cryptography, like using SSL everywhere and following best practices for key management and PKI. The overall message is that APIs require different security practices than traditional web apps.
Websites and applications are implementing social single sign-on to allow users to login using trusted authentication providers such as Google, Facebook, and even Salesforce. Join us to learn how to configure the OpenID Connect authentication provider to allow users to authenticate at Google to access a Salesforce environment. We'll also look at how you can relieve yourself of the burden of password management by having your web app login users via Salesforce.
OpenID Connect - a simple[sic] single sign-on & identity layer on top of OAut...Brian Campbell
Identity is ubiquitous. Regardless of the kind of applications you develop you will, at some point, almost certainly have to deal with identifying users of the app. Yet it's seldom a central part of the app’s value proposition and rarely a core competency for developers. Wouldn’t it be nice to outsource user authentication and free yourself from the liability and complexity of storing and managing passwords? OpenID Connect, just ratified earlier this year and backed by some big industry names, is emerging as the go to standard way to do exactly that. Connect allows you to easily and securely get an answer to the question: “What is the identity of the person currently using this browser or native app?” Unlike some of it’s predecessors, however, Connect has roots spanning the consumer, SaaS and enterprise space and is better suited to serve a diverse set of deployments. Come find out more about Connect in this talk from a seasoned veteran of the prestigious basement conference rooms at GlueCon.
This document summarizes Simon Willison's presentation on building the social web with OpenID. It discusses four problems with traditional usernames and passwords: they are insecure, creating new accounts is tedious, online identities are fragmented, and social software has too much overhead. OpenID is presented as a decentralized solution for single sign-on that allows users to authenticate using a URL as their identity. The document covers how OpenID works, considerations for implementing it, and its potential to help tie together a user's online profiles and identities across different services.
Simon Willison gives an overview of OpenID, a decentralized single sign-on system. OpenID allows users to authenticate using a URL of their choice rather than having separate usernames and passwords for each site. It provides benefits like reducing the number of passwords users need to remember and allowing them to retain control over their credentials. The talk also addresses questions around how OpenID works, how to implement it on a website, privacy implications, and other organizations involved in the OpenID community.
Presented at Webstock '08 on February 15th in Wellington, New Zealand. Social networks are an unavoidable part of life on the Web today, but most exist as walled gardens with interactions and identities trapped in a silo. OpenID is one of a number of initiatives that are trying to break down these walls and enable new social applications to bootstrap off each other.
OpenID is a decentralized authentication system that allows users to log in to multiple websites using a single digital identity. It solves problems like having too many usernames and passwords to remember across different accounts. OpenID uses URLs as unique identifiers and allows users to verify their identity by logging in through a trusted third party identity provider such as Google or AOL. While it outsources security to third parties, proponents argue that common practices like password reset emails already do this. OpenID allows for easier management of multiple online identities and personas.
OpenID is an open standard for decentralized authentication that allows users to log in to multiple websites using a single digital identity. It uses a URL as a person's identifier and allows them to prove control of that identifier through cryptographic means without needing to share any other private information. OpenID addresses common problems with user authentication across different websites and aims to be simple, secure, and interoperable.
This document discusses OpenID and user-centric digital identity. It provides an overview of OpenID, including how it works, its benefits over traditional username and passwords, and some limitations. The key points are:
- OpenID allows users to use a single digital identity across multiple websites without needing separate usernames and passwords for each one.
- It works by redirecting users to an identity provider to verify their identity with other "relying parties" like websites. This eliminates the need to register on new sites.
- Over 500 million users now have OpenID enabled identities, providing a simple way to prove who they are online without worrying about identities being scattered across many accounts. However, it also has some risks if the
OpenID is a decentralized single sign-on system that allows users to log into multiple websites using their existing identities, such as a URL like "username.openid.com". It provides benefits like reducing the need to create and remember multiple usernames and passwords. However, OpenID also faces challenges like potential identity theft if the authentication provider is hacked, and that its technical workings can be difficult to explain to average users. Overall, OpenID shows promise as a solution to many of the frustrations of the current web authentication system, but also needs continued development to address security and usability issues.
This is the keynote presentation that I gave at MyData 2018. It explains the connection between identity and personal data. Some of my story of how I began working on identity 15 years ago. The Domains of Identity, My master's report is explained and then core components of Self-Sovereign Identity is explained. I conclude sharing some thoughts on how we work together to build alignment.
This is a talk I was asked to give at the What is Universe? at the University of Oregon, (on their Portland Campus). I cover this history of the Internet Identity Workshop and talk about its core nature as a torus / bowl a feminine form and how this has resulted in the innovation of Self-Sovereign Identity
LinkedIn is a business-oriented social networking site with over 75 million users worldwide. It allows users to maintain a list of professional contacts and connections. These connections can be used to gain introductions to potential jobs, business opportunities, and candidates. Employers can use LinkedIn to post jobs and search for potential candidates, while job seekers can review hiring manager profiles and contacts. The presentation encourages customizing profiles, sharing, joining groups, and using LinkedIn to find new jobs.
Patterns to Bring Enterprise and Social Identity to the Cloud CA API Management
In this session, we will look at strategies to incorporate identity into cloud applications. Enterprise
identity or social login can both be a part of your go-to-cloud strategy, but you must plan for this
upfront, rather than try to retrofit identity and access control at a later date.
OpenID is an open standard that allows users to log in to multiple websites using a single digital identity. It offers globally unique identifiers for users rather than local identifiers used by individual websites. OpenID allows identity information and authentication processes to be shared across websites. Major technology companies support OpenID and it is integrated into many popular websites and applications. OpenID provides a way for formal systems like enterprises to connect with informal user-managed systems through a shared authentication method.
CIS14: Identifying Things (and Things Identifying Us)CloudIDSummit
Paul Madsen, Ping Identity
Discussing a security and identity model for things that do not make the existing password problem orders of magnitude worse (perhaps using identity protocols like OAuth & OpenID Connect), and how our things might facilitate our own interactions with applications.
Self-Sovereign Identity technology has enormous potential to empower individuals and address privacy challenges globally. It uses shared ledgers (blockchain) to give individuals the power to create and manage their own identifiers, collect verified claims and interact with others on the network on their terms. This lighting talk by one of the pioneers working on this new emerging layer of the internet for 15 years will give a high level picture of how it works covering the core standards and technologies along with outlining some potential use-cases.
This document provides an overview of digital identity concepts from a workshop presented by Kaliya "Identity Woman" Young. The summary includes:
1) Young discusses key concepts around digital identity including enrollment, attributes, identifiers, authentication, authorization, and user-centric/self-sovereign identity models.
2) Contexts for digital identity are explored including enterprises, government systems, and commons-based approaches.
3) Challenges with achieving user-centric digital identity are that it is a complex problem involving technology, legal, social, and business issues and requires changes to existing systems and behaviors.
4) Resources on digital identity properties and design principles are provided to help understand the challenges in building
Open ID & OAuth allows users to verify their identity across multiple websites without needing separate logins for each site. OpenID handles user authentication by allowing users to log in with an OpenID username and password. OAuth authorizes third party applications to access user data without sharing the user's actual credentials. Many major websites use these standards, including Google, Facebook, and Twitter. The document provides code examples for implementing OpenID and OAuth authentication.
The document discusses moving beyond passwords for user authentication on websites. It notes that passwords have been compromised in many large data breaches and advocates for stronger authentication using two or more factors such as something you know, have, or are. The document explores options for strong authentication like smart cards as well as delegation protocols like SAML, OAuth, and OpenID Connect that allow users to authenticate using existing identities from email or social media rather than creating new credentials. It emphasizes the need for any authentication solution to balance security, convenience, cost, and privacy.
Decentralized identities in DeFi can be achieved through various technical methods like attestations, anonymous credentials using zero-knowledge proofs, and decentralized identifiers. Bootstrapping credentials from legacy identity authorities is possible using oracles while maintaining user privacy. Future developments may focus on relying less on central authorities and more on webs of trust, proofs of personhood, and other innovations to establish identities without revealing sensitive personal information.
Natalie launched the first version of Lanyrd.com with a co-founder and her husband Simon, while on honeymoon in Casablanca. As the site took off, they realised their side project was destined to become something much bigger.
This talk will tell the story of Lanyrd from a two-week proof of concept to a fully-fledged startup, the lessons learned along the way about building and launching a product, running a company, raising investment and the entrepreneurship journey. This is the talk she wished she heard before getting started! In September 2013, just a week before the SmashingConf 2013, Lanyrd was acquired by Eventbrite.
OpenID in the Digital ID Landscape: A Perspective From the Past to the FutureNat Sakimura
Digital identity has been under a constant evolution for the last 30 years. It started from a simple access control via user account within a system to a shared credential among the systems, then to the federated identity and bring-your-own-identity (BYOI). Modern usages are not only for access control but include such purposes like digital on-boarding (account opening), employee and customer relationship management. Among the many technologies out there, OpenID seems to have gained popularity in the market that you are probably using it without knowing it. This session explains the positioning of OpenID in the digital ID landscape and explores the future potential for both corporations and individuals.
170724 JP/UK Open Banking Summit English TranslationNat Sakimura
This document summarizes a presentation by Nat Sakimura on the Financial API (FAPI) security profile. It discusses some security issues with the OAuth framework and how FAPI addresses these by combining techniques like PKCE, JAR, hybrid flow, and sender constrained tokens. FAPI has been adopted by organizations like Open Banking UK and aims to provide a standardized, interoperable yet secure profile for financial APIs. The presentation outlines the FAPI specifications and implementation guidance being developed within standards bodies.
Introduction to the FAPI Read & Write OAuth Profile - Jan 2018 UpdatesNat Sakimura
APIDays Paris 2018 presentaion by Nat Sakimura.
Talking about Part 1, 2, and new Part 3 with examples.
My twitter: @_nat_en
Follow me on Youtube: https://www.youtube.com/NatSakimura
Blog: https://nat.sakimura.org/
Introduction to the FAPI Read & Write OAuth ProfileNat Sakimura
It the presentation used in APIDays Berlin (2017-11-08) to explain the Financial API Read & Write Security profile's rationale and how it fulfilled the requirements.
Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the applic...Nat Sakimura
Nat Sakimura proposes applying the Basin-Cremers-Meier (BCM) principles to strengthen the OAuth 2.0 authorization code grant protocol against network attackers. The BCM principles aim to ensure cryptographic message components uniquely identify their origin and include identities and roles of all agents. Sakimura analyzes how the original OAuth messages satisfy the BCM principles poorly by lacking unique identifiers and integrity protection. He suggests modifications like adding unique redirect URIs, signing requests and responses, and including state/transaction binding IDs to better satisfy the principles and secure OAuth against network attackers.
OpenID Foundation FAPI WG: June 2017 UpdateNat Sakimura
This document discusses issues with using OAuth for financial APIs and the need to create an appropriate OAuth profile to address these issues. It outlines several factors that must be considered for a financial API OAuth profile, including message authentication, source authentication, destination authentication, and ensuring only one authorization server per client. The document provides examples of current message authentication, source authentication, and destination authentication problems with the OAuth framework and how a financial API profile could help solve them.
API Days 2016 Day 1: OpenID Financial API WGNat Sakimura
Nat Sakimura presents on the OpenID Foundation's Financial API Working Group. The group aims to develop standards for financial APIs that allow applications to access user financial data and interact with accounts, while giving users control over privacy and security. The standards will be developed openly under OpenID Foundation's IPR policies. The work will build on existing standards like OAuth, JSON, and OpenID Connect. The group has made progress defining a multi-part standard, starting with read-only APIs, and hopes to eventually submit standards to ISO for broader adoption. Sakimura invites attendees to join and contribute to the working group.
1. In the era of mobile, OAuth 2.0 is the protocol of the choice. 2. However, RFC6749 is a framework and needs to be profiled appropriately for use cases.
3. FAPI WG @ OIDF is taking such task for Financial APIs and securing it using RFC7636, JWT Client Authentication/TLS Client Authentication, OpenID Connect, etc.
4. FAPI WG is collaborating with many stakeholders including financial institutions and fintech companies, etc.
5. Read only security profile going to OIDF votes.
6. Overview of the requirements for Read Only and Write Access security profiles are discussed.
OpenID Foundation Foundation Financial API (FAPI) WGNat Sakimura
The document discusses the need for a standardized financial API to enable applications to access and interact with financial account data, replacing outdated practices like screen scraping. It proposes that the OpenID Foundation establish a Financial API working group to develop such standards. The group would specify JSON schemas, REST APIs, and security recommendations to allow applications to securely utilize and manage user financial data with the goal of facilitating innovation in financial technology.
This document discusses Symmetric Proof of Possession for Code (SPOP), a proposed solution to mitigate code interception attacks in OAuth public clients. It describes the problem of attackers intercepting authorization codes instead of the client. The solution proposes having clients generate a cryptographic code challenge to send with authorization requests and verify later with a code verifier. The draft proposes support for plain or SHA256 challenges and defines error responses. It is in IETF last call and seeks comments to improve text clarifications and define error responses.
The document proposes a transient client secret extension for OAuth 2.0 public clients. It addresses the problem that on iOS, app selection by custom URL schemes is non-deterministic, so a malicious app could intercept the code by registering the same custom scheme as the target app. As public clients do not have a client secret, the access token could be obtained by the malicious app with high probability. The proposed extension assigns a transient client secret to public clients that is only valid for the initial authorization request to mitigate this risk.
As part of exercise to test the extensibility of OpenID Connect to other protocols than HTTP, we have created a custom scheme binding. This is still a rough sketch but should give you some ideas on what it is. It may seem to be a bit of stretch, but has a niche characteristics that it does not "leak" information to external OPs.
There will be a companion RP side as well, which would be a more normal case.
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...Tatiana Kojar
Skybuffer AI, built on the robust SAP Business Technology Platform (SAP BTP), is the latest and most advanced version of our AI development, reaffirming our commitment to delivering top-tier AI solutions. Skybuffer AI harnesses all the innovative capabilities of the SAP BTP in the AI domain, from Conversational AI to cutting-edge Generative AI and Retrieval-Augmented Generation (RAG). It also helps SAP customers safeguard their investments into SAP Conversational AI and ensure a seamless, one-click transition to SAP Business AI.
With Skybuffer AI, various AI models can be integrated into a single communication channel such as Microsoft Teams. This integration empowers business users with insights drawn from SAP backend systems, enterprise documents, and the expansive knowledge of Generative AI. And the best part of it is that it is all managed through our intuitive no-code Action Server interface, requiring no extensive coding knowledge and making the advanced AI accessible to more users.
GraphRAG for Life Science to increase LLM accuracyTomaz Bratanic
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on integration of Salesforce with Bonterra Impact Management.
Interested in deploying an integration with Salesforce for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Ivanti’s Patch Tuesday breakdown goes beyond patching your applications and brings you the intelligence and guidance needed to prioritize where to focus your attention first. Catch early analysis on our Ivanti blog, then join industry expert Chris Goettl for the Patch Tuesday Webinar Event. There we’ll do a deep dive into each of the bulletins and give guidance on the risks associated with the newly-identified vulnerabilities.
This presentation provides valuable insights into effective cost-saving techniques on AWS. Learn how to optimize your AWS resources by rightsizing, increasing elasticity, picking the right storage class, and choosing the best pricing model. Additionally, discover essential governance mechanisms to ensure continuous cost efficiency. Whether you are new to AWS or an experienced user, this presentation provides clear and practical tips to help you reduce your cloud costs and get the most out of your budget.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on automated letter generation for Bonterra Impact Management using Google Workspace or Microsoft 365.
Interested in deploying letter generation automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
Best 20 SEO Techniques To Improve Website Visibility In SERPPixlogix Infotech
Boost your website's visibility with proven SEO techniques! Our latest blog dives into essential strategies to enhance your online presence, increase traffic, and rank higher on search engines. From keyword optimization to quality content creation, learn how to make your site stand out in the crowded digital landscape. Discover actionable tips and expert insights to elevate your SEO game.
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...alexjohnson7307
Predictive maintenance is a proactive approach that anticipates equipment failures before they happen. At the forefront of this innovative strategy is Artificial Intelligence (AI), which brings unprecedented precision and efficiency. AI in predictive maintenance is transforming industries by reducing downtime, minimizing costs, and enhancing productivity.
20. Connect
OpenID
Signed Request
• Works only with
a single identity
provider
• Proprietary
signature format
ID Token
• Works with
multiple identity
providers
• IETF JSON Web
Signature
23. Connect
OpenID
An Identity Layer provides:
• is the user that got authenticated
Who
• was he authenticated
Where
• was he authenticated
When
• was he authenticated
How
• attributes he can give you
What
• he is providing them
Why
29. Connect
OpenID
Interoperable
• openid, profile, email, address, phone
Standard scopes
• Request object and claims
Method to ask for
more granular claims
• Info about the authenticated user
ID Token
• Get attributes about the user
• Translate the tokens
UserInfo endpoint
30. Connect
OpenID
Simple & Mobile Friendly
JSON Based
REST Friendly
In simplest cases,
just copy and paste
Mobile & App
Friendly
e.g., ID Token is signed JSON
{
"iss": "https://client.example.com",
”sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "2",
"at_hash":
"MTIzNDU2Nzg5MDEyMzQ1Ng"
}
32. Connect
OpenID
Flexible
• Through Request Object (JSON)
• Data Minimization
Granular
Request
• Does not disclose data recipients
to data sources
Aggregated
Claims
• Decentralized Data Storage
Distributed
Claims
33. Connect
OpenID
Choice of your provider
Can be Google,
eBay, AOL,
Deutsche
Telecom etc.
Can be your
Phone =>
Self-Issued
Provider
35. Connect
OpenID
Name: Alice de
Wonderland
Mail: alice@example.com
Notary: Google.
Official
Google
Seal
株式会
社グー
グル印
Name: Alice de
Wonderland
Mail: alice@example.com
Notary: Google.
SAML Authentication
1. Who are you. Get me
a referral letter.
Do not forget about
Your email!
2. Plz write me a
referral letter。
3. Here you are
Alice
4. Here is the
certificate.
notary
Eve
Official
Google
Seal
36. Connect
OpenID
1. Who are YOU? Give me
a valet key to your house.
Then I will trust that
you are the owner of the house.
2. Can you give me
a valet key to my house?
3. Here you are!
Alice
4. Her is the key!
Pseudo-Authentication using OAuth
Apartment
Controller
Eve
37. Connect
OpenID
OpenID Connect Authentication
1. Who are you. Get me
a referral letter.
Do not forget about
Your email!
2. Give Eve the locker
Key and a referral
letter.
3. Here you are!
Alice
4. Here you are
Date:2011/5/15 11:00:04
Level of Assurance:2
Verifier:Google
Official
Google
Seal
Butler
Locker
Locker
Eve
Date:2011/5/15 11:00:04
Level of Assurance:2
Verifier:Google
Official
Google
Seal
38. Connect
OpenID
OpenID Connect's Clams aggregation and
distributed claims.
Name: Alice de Wanderland
DoB: 1989/3/3
Sex: F
Address: 135 Broadway., NY,
NY
NY City
Official
Seal
Locker
UserInfo Endpoint
Site X
Site Y
Site Z
Eve
50. Connect
OpenID
SCIM Enterprise User Schema Extension
• employeeNumber
– Numeric or alphanumeric identifier assigned to a person, typically
based on order of hire or association with an organization.
• costCenter
– Identifies the name of a cost center. organization Identifies the name
of an organization.
• division
– Identifies the name of a division.
• department
– Identifies the name of a department.
• manager
– The User's manager. A complex type that optionally allows Service
Providers to represent organizational hierarchy by referencing the "id"
attribute of another User.
59. Connect
OpenID
Working Group Members
• Key working group participants:
– Nat Sakimura – Nomura Research Institute – Japan
– John Bradley – Ping Identity – Chile
– Breno de Medeiros – Google – US
– Axel Nennker – Deutsche Telekom – Germany
– Torsten Lodderstedt – Deutsche Telekom – Germany
– Roland Hedberg – Umeå University – Sweden
– Andreas Åkre Solberg – UNINETT – Norway
– Chuck Mortimore – Salesforce – US
– Brian Campbell – Ping Identity – US
– George Fletcher – AOL – US
– Justin Richer – Mitre – US
– Nov Matake – Independent – Japan
– Mike Jones – Microsoft – US
• By no means an exhaustive list!
62. Connect
OpenID
How We Make It Simple
• Build on OAuth 2.0
• Use JavaScript Object Notation (JSON)
• Build only the pieces that you need
• Goal: Easy implementation on all modern
development platforms
64. Connect
OpenID
A Look Under the Covers
• ID Token
• Claims Requests
• UserInfo Claims
• Example Protocol Messages
65. Connect
OpenID
OpenID Connect Authentication
1. Who are you. Get me
a referral letter.
Do not forget about
Your email!
2. Give Eve the locker
Key and a referral
letter.
3. Here you are!
Alice
4. Here you are
Date:2011/5/15 11:00:04
Level of Assurance:2
Verifier:Google
Official
Google
Seal
Butler
Locker
Locker
Bob
Date:2011/5/15 11:00:04
Level of Assurance:2
Verifier:Google
Official
Google
Seal
Access Token
ID Token
66. Connect
OpenID
ID Token
• JWT representing logged-in session
• Claims:
– iss – Issuer
– sub – Identifier for subject (user)
– aud – Audience for ID Token
– iat – Time token was issued
– exp – Expiration time
– nonce – Mitigates replay attacks
– at_hash – Left hash of the access token
– azp – Authorized Party
70. Connect
OpenID
Using Access Token only for Authentication is
Dangerous.
1. Who are you. Get me
a referral letter.
Do not forget about
Your email!
2. Give Eve the locker
Key and a referral
letter.
3. Here you are!
Alice
4. Here you are
Butler
Access Token
Eve
71. Connect
OpenID
OpenID Connect's Clams aggregation and
distributed claims.
Name: Alice de Wanderland
DoB: 1989/3/3
Sex: F
Address: 135 Broadway., NY,
NY
NY City
Official
Seal
Locker
UserInfo Endpoint
Site X
Site Y
Site Z
Bob
81. Connect
OpenID
Resources
• OpenID Connect
– http://openid.net/connect/
• OpenID Connect Working Group Mailing List
– http://lists.openid.net/mailman/listinfo/openid-specs-ab
• OpenID Connect Interop Wiki
– http://osis.idcommons.net/
• OpenID Connect Interop Mailing List
– http://groups.google.com/group/openid-connect-interop
• Mike Jones’ Blog
– http://self-issued.info/
• Nat Sakimura’s Blog
– http://nat.sakimura.org/
• John Bradley’s Blog
– http://www.thread-safe.com/
82. Connect
OpenID
Current Status
• Waiting for dependencies to be completed
• JWS, JWE, JWA, JWK
IETF JOSE
WG
• JSON Web Token (JWT)
IETF OAuth
WG
• WebFinger
IETF Apps
WG