Re: [Txauth] alternative charter writeup

UX constrained devices?

On Mon, Jan 13, 2020 at 9:30 AM Justin Richer <jricher@mit.edu> wrote:

> I think it should be I struggled on how to capture that. The key element
> here is that there’s one device doing the request and another doing the
> interaction. This pattern is also used in CIBA and some UMA style flows, so
> it’s not just about the nature of the client but also about the nature of
> the users involved.
>
> So for now that’s firmly in “and other” but I’m open to suggestion!
>
>
>  — Justin
>
> On Jan 13, 2020, at 2:59 AM, Lee McGovern <Lee_McGovern@swissre.com>
> wrote:
>
> "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> wrote:
>
> This looks even better! Thanks Justin.
>
> What do others think of the proposed charter now?
> ᐧ
>
> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <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> 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.
>
>
> ᐧ
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
> --
> Txauth mailing list
> 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. --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>