13 US states have already rolled out mobile digital driver's licenses (mDLs), and many more are testing the waters. Why the buzz? These government-issued digital IDs promise game-changing benefits: enhanced privacy, smoother online transactions, and a streamlined process for everything from opening a bank account to securing a loan.
So, here's the real question: how will mDLs transform remote ID verification?
The Access Evaluation Request is an HTTPS request with content-type of application/json. Its body is a JSON object that contains the Access Evaluation Request, as defined in Section 6.1.
The following is a non-normative example of the HTTPS binding of the Access Evaluation Request:
The success response to an Access Evaluation Request is an Access Evaluation Response. It is an HTTPS response with a status code of 200, and content-type of application/json. Its body is a JSON object that contains the Access Evaluation Response, as defined in Section 6.2.
Following is a non-normative example of an HTTPS Access Evaluation Response:
The following error responses are common to all methods of the Authorization API. The error response is indicated by an HTTPS status code (Section 15 of [RFC9110]) that indicates error.
The following errors are indicated by the status codes defined below:
7.1.3.エラー応答
以下のエラー応答は、Authorization API のすべてのメソッドに共通です。エラー応答は、RFC9110セクション15に定義されているHTTPS ステータス コード によって識別されます。
Note: HTTPS errors are returned by the PDP to indicate an error condition relating to the request or its processing, and are unrelated to the outcome of an authorization decision, which is always returned with a 200 status code and a response payload.
To make this concrete: * a 401 HTTPS status code indicates that the caller (policy enforcement point) did not properly authenticate to the PDP - for example, by omitting a required Authorization header, or using an invalid access token. * the PDP indicates to the caller that the authorization request is denied by sending a response with a 200 HTTPS status code, along with a payload of { "decision": false }.
All requests to the API MAY have request identifiers to uniquely identify them. The API client (PEP) is responsible for generating the request identifier. If present, the request identifier SHALL be provided using the HTTPS Header X-Request-ID. The value of this header is an arbitrary string. The following non-normative example describes this header:
7.1.4.リクエストの識別
API へのすべてのリクエストには、リクエストを一意に識別するためのリクエスト識別子が含まれる場合があります。API クライアント (PEP) は、リクエスト識別子を生成する責任があります。存在する場合、リクエスト識別子は HTTPS ヘッダーを使用して提供される必要がありますX-Request-ID。このヘッダーの値は任意の文字列です。次の非規範的な例は、このヘッダーについて説明しています:
POST /access/v1/evaluation HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716
A PDP responding to an Authorization API request that contains an X-Request-ID header MUST include a request identifier in the response. The request identifier is specified in the HTTPS Response header: X-Request-ID. If the PEP specified a request identifier in the request, the PDP MUST include the same identifier in the response to that request.
The following is a non-normative example of an HTTPS Response with this header:
7.1.5.レスポンスにおけるリクエストの識別
ヘッダーを含む Authorization API リクエストに応答する PDP はX-Request-ID、レスポンスにリクエスト識別子を含める必要があります。リクエスト識別子は、HTTPS レスポンス ヘッダー（X-Request-ID）で指定されます。PEP がリクエストにリクエスト識別子を指定した場合、PDP はそのリクエストへのレスポンスに同じ識別子を含める必要があります
以下は、このヘッダーを含む HTTPS レスポンスの非標準的な例です:
HTTP/1.1 OK
Content-type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716
The Access Evaluation API defines the message exchange pattern between a client (PEP) and an authorization service (PDP) for executing a single access evaluation.
6.アクセス評価API
アクセス評価 API は、単一のアクセス評価を実行するためのクライアント (PEP) と認可サービス (PDP) 間のメッセージ交換パターンを定義します
まずはリクエストからです。
6.1. The Access Evaluation API Request
The Access Evaluation request is a 4-tuple constructed of the four previously defined entities:
subject: REQUIRED. The subject (or principal) of type Subject
action: REQUIRED. The action (or verb) of type Action.
resource: REQUIRED. The resource of type Resource.
context: OPTIONAL. The context (or environment) of type Context.
In addition to a "decision", a response may contain a "context" field which can be any JSON object. This context can convey additional information that can be used by the PEP as part of the decision evaluation process. Examples include:
A Reason Object specifies a particular reason. It is a JSON object that has the following fields:
id: REQUIRED. A string value that specifies the reason within the scope of a particular response.
reason_admin: OPTIONAL. The reason, which MUST NOT be shared with the user, but useful for administrative purposes that indicates why the access was denied. The value of this field is a Reason Field object (Section 6.2.3.1.1).
reason_user: OPTIONAL. The reason, which MAY be shared with the user that indicates why the access was denied. The value of this field is a Reason Field object (Section 6.2.3.1.1).
The following is a non-normative example of a Reason Object:
The information model for requests and responses include the following entities: Subject, Action, Resource, Context, and Decision. These are all defined below.
A Subject is the user or robotic principal about whom the Authorization API is being invoked. The Subject may be requesting access at the time the Authorization API is invoked.
A Subject is a JSON ([RFC8259]) object that contains two REQUIRED keys, type and id, which have a value typed string, and an OPTIONAL key, properties, with a value of a JSON object.
type:
REQUIRED. A string value that specifies the type of the Subject.
id:
REQUIRED. A string value containing the unique identifier of the Subject, scoped to the type.
properties:
OPTIONAL. A JSON object containing any number of key-value pairs, which can be used to express additional properties of a Subject.
The following is a non-normative example of a Subject:
5.1.主体
サブジェクトとは、Authorization API が呼び出されるユーザーまたはロボット プリンシパルです。サブジェクトは、Authorization API が呼び出された時点でアクセスを要求している可能性があります
Many authorization systems are stateless, and expect the client (PEP) to pass in any properties or attributes that are expected to be used in the evaluation of the authorization policy. To satisfy this requirement, Subjects MAY include zero or more additional attributes as key-value pairs, under the properties object.
An attribute can be single-valued or multi-valued. It can be a primitive type (string, boolean, number) or a complex type such as a JSON object or JSON array.
The following is a non-normative example of a Subject which adds a string-valued department property:
The IP Address of the Subject, identified by an ip_address field, whose value is a textual representation of an IP Address, as defined in Textual Conventions for Internet Network Addresses [RFC4001].
The following is a non-normative example of a subject which adds the ip_address property:
A Resource is the target of an access request. It is a JSON ([RFC8259]) object that is constructed similar to a Subject entity. It has the follow keys:
type:
REQUIRED. A string value that specifies the type of the Resource.
id:
REQUIRED. A string value containing the unique identifier of the Resource, scoped to the type.
properties:
OPTIONAL. A JSON object containing any number of key-value pairs, which can be used to express additional properties of a Resource.
Since many services follow a Create-Read-Update-Delete convention, a set of common Actions are defined. That said, an Action may be specific to the application being accessed or shared across applications but not listed in the common Actions below.
The following common Actions are defined:
can_access: A generic Action that could mean any type of access. This is useful if the policy or application is not interested in different decisions for different types of Actions.
can_create: The Action to create a new entity, which MAY be defined by the resource field in the request.
can_read: The Action to read the content. Based on the Resource being accessed, this could mean a list functionality or reading an individual Resource's contents.
can_update: The Action to update the content of an existing Resource. This represents a partial update or an entire replacement of an entity that MAY be identified by the Resource in the request.
can_delete: The Action to delete a Resource. The specific entity MAY be identified by the Resource in the request.
PDP Policies MAY incorporate common Action names to provide different decisions based on the Action.
The Context object is a set of attributes that represent environmental or contextual data about the request such as time of day. It is a JSON ([RFC8259]) object.
The following is a non-normative example of a Context:
The Authorization API enables Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) to communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings. The Authorization API is served by the PDP and is called by the PEP. The Authorization API includes an Evaluation endpoint, which provides specific access decisions. Other endpoints may be added in the future for other scenarios, including searching for subjects or resources.
概要
Authorization API により、ポリシー決定ポイント (PDP) とポリシー適用ポイント (PEP) は、互いの内部動作を知らなくても、認可要求と決定を相互に通信できます。Authorization API は PDP によって提供され、PEP によって呼び出されます。Authorization API には、特定のアクセス決定を提供する評価エンドポイントが含まれています。将来的には、サブジェクトやリソースの検索など、他のシナリオ用に他のエンドポイントが追加される可能性があります。
Computational services often implement access control within their components by separating Policy Decision Points (PDPs) from Policy Enforcement Points (PEPs). PDPs and PEPs are defined in XACML and NIST's ABAC SP 800-162. Communication between PDPs and PEPs follows similar patterns across different software and services that require or provide authorization information. The Authorization API described in this document enables different providers to offer PDP and PEP capabilities without having to bind themselves to one particular implementation of a PDP or PEP.
1.はじめに
計算サービスでは、ポリシー決定ポイント (PDP) とポリシー適用ポイント (PEP) を分離することで、コンポーネント内にアクセス制御を実装することがよくあります。PDP と PEP は、XACMLと NIST の ABAC SP 800-162定義されています。PDP と PEP 間の通信は、認可情報を必要とする、または認可情報を提供するさまざまなソフトウェアやサービスで同様のパターンに従います。このドキュメントで説明するAuthorization API を使用すると、さまざまなプロバイダーが、特定の PDP または PEP の実装に縛られることなく、PDP および PEP 機能を提供できます
基本的にはPDP APIの標準化をしていきますよ、ってことですね。
2. Model
The Authorization API is a transport-agnostic API published by the PDP, to which the PEP acts as a client. Possible bindings of this specification, such as HTTPS or gRPC, are described in Transport.
Authorization for the Authorization API itself is out of scope for this document, since authorization for APIs is well-documented elsewhere. For example, the Authorization API's HTTPS binding MAY support authorization using an Authorization header, using a basic or bearer token. Support for OAuth 2.0 ([RFC6749]) is RECOMMENDED.
2.モデル
Authorization API は PDP によって公開されたトランスポートに依存しない API であり、PEP はクライアントとして機能します。HTTPS や gRPC など、この仕様の可能なバインディングについては、トランスポートで説明されています
Authorization API 自体の認可は、API の認可については他の場所で十分に文書化されているため、このドキュメントの範囲外です。たとえば、Authorization API の HTTPS バインディングは、ヘッダーAuthorization、basicまたはトークンを使用した認可をサポートする場合があります。OAuth 2.0 ( [ RFC6749 ] )bearerのサポートが推奨されます
The core feature of the Authorization API is the Access Evaluation API, which enables a PEP to find out if a specific request can be permitted to access a specific resource. The following are non-normative examples:
Can Alice view document #123?
Can Alice view document #123 at 16:30 on Tuesday, June 11, 2024?
Can a manager print?
3.特徴
Authorization API のコア機能はアクセス評価 API であり、これにより PEP は特定のリクエストが特定のリソースへのアクセスを許可されるかどうかを確認できます。以下は非規範的な例です:
This document describes the API version 1. Any updates to this API through subsequent revisions of this document or other documents MAY augment this API, but MUST NOT modify the API described here. Augmentation MAY include additional API methods or additional parameters to existing API methods, additional authorization mechanisms, or additional optional headers in API requests. All API methods for version 1 MUST be immediately preceded by the relative URL path /v1/.
4. APIバージョン
このドキュメントでは、API バージョン 1 について説明します。このドキュメントまたは他のドキュメントの今後の改訂によるこの API の更新では、この API を拡張できますが、ここで説明する API を変更してはなりません。拡張には、追加の API メソッド、既存の API メソッドへの追加のパラメーター、追加の認証メカニズム、または API リクエスト内の追加のオプション ヘッダーが含まれる場合があります。バージョン 1 のすべての API メソッドの直前には、相対 URL パスがなければなりませ/v1/。
The authentication world has mature specifications that are universally adopted, such as OAuth2 and OpenID Connect. This has helped the industry solve "single sign-on for the web".
But help is one the way! OpenID AuthZEN aims to become the "OpenID Connect of authorization", and has just entered the review phase for the first Implementer's Draft of the Authorization API version 1.0.
Having served as co-chair of the WG and co-editor of the spec, this means a lot to us at Aserto. Why?
しかし、助けは必ずあります! OpenID AuthZEN は「認可の OpenID Connect」になることを目指しており、Authorization API バージョン 1.0の最初の実装者ドラフトのレビュー段階に入ったところです。
WG の共同議長および仕様の共同編集者を務めた Aserto にとって、これは大きな意味を持ちます。なぜでしょうか?
わくわくしますね！この問題が解けると確かに大きなインパクトです。
Why standardize authorization?
Standards efforts are multi-year affairs, so we don't take them lightly. Standardizing a developer technology needs three things to succeed:
It addresses a significant pain point.
Competing technology providers find areas where standardization doesn't erode differentiation, but accelerates adoption.
It provides significant benefits to consumers and end-users of the technology, which drives adoption.
Early in my career, around 1993, I witnessed this first hand with Open Database Connectivity, or ODBC. Consumers wanted data-centric applications (Excel, Access, Visual Basic, Powerbuilder, and countless more) to be able to talk to a bunch of data sources (Oracle, Sybase, SQL Server, DB2, Informix, and many others).
This is what we call an "N * M" problem: N applications need to build connectors to M data sources. Wasteful and expensive.
ODBC addressed this challenge by defining a universal data access API, which database vendors could implement, and applications could consume, transforming it into an "N + M" problem. All of the sudden, any data application could immediately talk to a whole bunch of data sources simply by being a consumer of ODBC.
My startup, NEON Systems, bet on this standard and rode its success by integrating data-centric applications with a wide variety of enterprise data sources. NEON was so successful it went public in 1999.
Two decades after ODBC, OpenID Connect (OIDC) became a standard that solved a similar problem. N SaaS applications needed to integrate with M corporate identity providers. By adopting the OIDC protocol, each SaaS app allows its users to sign-in with their corporate identity provider (Okta, Azure AD, Google Workspace, Ping ID, etc).
Admins no longer have to worry about corporate users creating their own logins on each SaaS application - they can use a single corporate login across all these applications. Onboarding and offboarding become a breeze!
At Microsoft, our vision for this started with SAML, WS-Security, and WS-Federation in the early 2000's, but it wasn't until 2013 that OIDC reached its tipping point. The journey took a while, but the result has been nothing short of transformational.
OpenID Connect
ODBC の 20 年後、OpenID Connect (OIDC) が同様の問題を解決する標準になりました。N個のSaaS アプリケーションをM個の企業 ID プロバイダーと統合する必要がありました。OIDC プロトコルを採用することで、各 SaaS アプリのユーザーは企業 ID プロバイダー (Okta、Azure AD、Google Workspace、Ping ID など) を使用してサインインできるようになります。
Microsoft では、このビジョンは 2000 年代初頭に SAML、WS-Security、WS-Federation から始まりましたが、OIDC が転換点に達したのは 2013 年になってからでした。この道のりには時間がかかりましたが、その結果はまさに変革をもたらすものでした。
まぁ、この辺りまでは歴史の話ですな。
Open ID AuthZEN
Fast forward a decade to 2024: the same "N * M" problem exists in the authorization space. Every corporate application has its own way of assigning permissions to users. And the solution is similar to how applications have externalized authentication to an OIDC-compliant IDP: externalizing authorization to an AuthZEN-compliant Policy Decision Point (PDP).
Applications that do this not only save a bunch of time and effort rolling out their own bespoke authorization. They also allow IT administrators to enforce common policies across applications, ensure compliance across applications, and answer questions like "which users have access to which resources" across applications.
While authorization vendors want to differentiate on expressing policies, ensuring compliance, facilitating forensics, and managing authorization at scale, none of us really care about what the authorization API actually looks like. We all have similar APIs that are arbitrarily different, and they are not a real source of differentiation.
Standardizing the way a policy enforcement point (PEP) such as an application or API gateway calls an authorization platform (PDP) greatly reduces the friction of integrating the PEP with a wide variety of authorization solutions. It helps everyone:
Applications and API gateways can integrate with a bunch of externalized authorization systems using a single API, instead of creating bespoke integrations with each.
Authorization platforms become relevant to a broader set of applications and other policy enforcement points.
IT Administrators have a single "Authorization control plane" to manage policies and entitlements, and answer questions such as "what resources does this user have access to".
認可ベンダーは、ポリシーの表現、コンプライアンスの確保、フォレンジックの促進、大規模な認可の管理で差別化を図りたいと考えていますが、認可 API が実際にどのようなものであるかについては、誰も気にしていません。ベンダーは皆、任意に異なる類似の API を持っており、それらは差別化の本当の源ではありません。
アプリケーションや API ゲートウェイなどのポリシー適用ポイント (PEP) が認可プラットフォーム (PDP) を呼び出す方法を標準化すると、PEP をさまざまな認可ソリューションと統合する際の摩擦が大幅に軽減されます。これにより、すべての人が次のメリットを享受できます。
アプリケーションと API ゲートウェイは、それぞれにカスタマイズされた統合を作成する代わりに、単一の API を使用して多数の外部認証システムと統合できます。
So standardizing authorization is important. Why celebrate this milestone?
We started the OpenID AuthZEN WG in late October 2023. In one short year, we've been able to define a number of iterations of our first spec, the PEP-PDP API. We now have 13 interoperable implementations of a preview version of this spec.
We've learned quite a bit from the interop events we conducted at Identiverse 2024 and EIC 2024, and now have a candidate Implementer's Draft.
This milestone means that vendors can safely incorporate AuthZEN into their products, without worrying that the spec will "move under them". This also means that Policy Enforcement Points, such as API Gateways, SaaS applications, and identity providers can start calling out to AuthZEN PDPs to make authorization decisions.
The review and voting period extends through November 9, 2024. At that point, we will have a formal Implementer's Draft.
Aserto is committed to incorporating AuthZEN in a first-class way into our authorization engine, Topaz, as well as our commercial products.
In addition, we're looking forward to working with the community to create developer SDKs for a wide variety of languages, and working with API gateway vendors to make it trivial to call an AuthZEN-compliant PDP from a request filter.
The next AuthZEN interop event is at Authenticate 2024 on October 15, 2024. We plan on testing the next iteration of the spec, which defines how to send multiple evaluations in a single request, facilitating scenarios such as turning on and off features in a web or native UI based on a user's permissions.
We have lofty goals for AuthZEN. We will define a search API which standardizes answering questions like "which resources does this user have access to", and "which users can access this resource".
We also plan on defining ways in which upstream data sources can send data updates to policy decision points and policy information points, so that PDPs can have the latest user, group, and relationship information when evaluating access decisions.
今後の仕事
AuthZEN には高い目標があります。 「このユーザーはどのリソースにアクセスできるか」や「どのユーザーがこのリソースにアクセスできるのか」といった質問への回答を標準化する検索 API を定義します。
投稿
