Re: [Txauth] alternative charter writeup

"Web, mobile, single-page, and other types of client applications"

Should device (as in device flow) be explicitly mentioned here?

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Sent: Samstag, 11. Januar 2020 08:11
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>; txauth@ietf.org
Subject: Re: [Txauth] alternative charter writeup

+1

On Sat, Jan 11, 2020 at 04:56 Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
This looks even better! Thanks Justin.

What do others think of the proposed charter now?
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=c2542a73-9b36-42f1-b091-b07ceade18ee]ᐧ

On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:
Thanks, Dick. I’ve been working on an updated charter based on everyone’s feedback, and I was aiming to have out today anyway, so this timing is helpful. So here’s my take on a new charter, incorporating some of your points below:

This group is chartered to develop a delegation protocol for identity, authorization, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0 and OpenID Connect.

The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will be initiated by the client interacting directly with the authorization server (in contrast with OAuth 2 which is initiated by the client redirecting the user’s browser). The client will involve the authorizing party as necessary through interaction mechanisms indicated by the protocol.

Additionally, the delegation process will allow for:

- Fine-grained specification of resource access
- Approval of identity claims and multiple resources in a single interaction
- Delegation between multiple users
- Web, mobile, single-page, and other types of client applications

The group will define extension points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession
- User interaction mechanisms including web and non-web methods
- Mechanisms for providing user, software, organization, and other pieces of information used in authorization decisions
- Token presentation mechanisms and key bindings

Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify porting from OAuth 2.0 and OpenID Connect to the new protocol where possible.

While the initial work will focus on using HTTP for communication between the client and the authorization server, the working group will seek to take advantage of optimization features of HTTP2 and HTTP3, and will strive to enable simple mapping to other protocols such as COAP.

On Jan 10, 2020, at 12:04 PM, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:

Hey

I've written an alternative charter that I hope captures some of the feedback on Justin's charter.

I found it easier to rewrite the charter to broaden the marketplace of ideas.

Key ideas:

- This work supports existing OAuth 2.0, and OpenID Connect use cases.

- The client interacts directly with the authorization server.

/Dick

----

This group is chartered to develop a delegated identity and authorization protocol.. The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0, and OpenID Connect. In contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated by redirecting the user's browser to an authorization server, this protocol will be initiated by the client directly interacting with the authorization server..

Additionally, the protocol will allow:
- fine-grained specification of resource access
- the user to approve requests for identity claims and access to multiple resources in one interaction
- web, mobile, single-page, and other client applications
- taking advantage of optimization features in HTTP2 and HTTP3

The group will define extension points for this protocol to allow for flexibility in areas including:

- discovery of the authorization server
- cryptographic agility for keys, message signatures, and proof of possession
- user interaction mechanisms including web and non-web methods- token presentation mechanisms and key bindings

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse existing semantics such as client identifiers, OAuth 2.0 scopes and access tokens, and OpenID Connect ID Tokens and claims.

While the initial work will focus on using HTTP for communication between the client and the authorization server, the working group will strive to enable simple mapping to other protocols such as COAP.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=4100f11c-15ca-4d45-bbd2-c029965821fb]ᐧ
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
Sent from a mobile device, please excuse any typos

This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information.

Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.