What additional standards should we consider implementing (long-term)?

[christiansmith]

At present we have a pretty good handle on OAuth 2.0 and OpenID Connect. Our in the near future will be centered around OIDC certification and achieving 100% implementation. Along with other improvements like the CLI rewrite and other additional production support, this brings us most of the way toward a stable release (0.2.0).

Looking farther ahead, we should start the conversation about what additional specs and standards we ought to implement. Here are a few candidates:

• OpenID Connect related
  • OpenID Account Chooser – basic | advanced
  • OpenID Connect Native Application Token Provisioning Profile
  • OpenID Connect Native Application Token Agent API Bindings
  • Authorization Cross Domain Code
  • OpenID Native Apps Working Group – repos
  • WebFinger
• FIDO
• UMA
• SCIM
• ABAC
• XACML
• Using XACML Policies as OAuth Scope
• OpenAz

I'll add to this list and organize further based on the discussion.

[christiansmith]

Also see #180

[christiansmith]

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

[christiansmith]

OAuth 2.0 Proof-of-Possession (PoP) Security Architecture

[christiansmith]

Risk-Adaptable Access Control (RAdAC)

• paper
• slides

[christiansmith]

Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants

[christiansmith]

JSON Profile of XACML 3.0 Version 1.0

[christiansmith]

I don't see any standards for this, but we've had a few conversations with users about KYC. It's an interesting problem and we should probably add something to the roadmap. I'm wondering how some application of blockchain might fit in here as well.

[christiansmith]

OAuth 2.0 Token Introspection

This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

[christiansmith]

Proof Key for Code Exchange by OAuth Public Clients

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").

[christiansmith]

Authorization Cross Domain Code 1.0

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and RESTful manner.

The acdc grant allows a Authorization Server to issue a grant that can be redeemed by a token endpoint that is not tightly coupled to the issuing Authorization server.

A single Authorization Server (AS) authorization endpoint may in this way support multiple token endpoints, those endpoints may be in diffrent policy domains, including ones run by Software as a Service providers.