Subject: [Txauth] alternative charter writeup

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 09:04:49 -0800

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.

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 15:43:48 -0500

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 <[email-masked]> 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 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.
> 
> - the user to approve requests for identity claims and access to multiple resources in one interaction
> 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- 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 18:56:15 -0800

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 <[email-masked]> 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.
>
> - Mechanisms for providing user, software, organization, and other pieces
> of information used in authorization decisions
> 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.
>
> 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.
>

---

From: Adrian Hope-Bailie <[email-masked]>
Date: Sat, 11 Jan 2020 09:11:10 +0200

+1

On Sat, Jan 11, 2020 at 04:56 Dick Hardt <[email-masked]> wrote:

>> protocol.. The use cases supported by this protocol will include widely
>> server..
-- 
Sent from a mobile device, please excuse any typos

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Jan 2020 23:08:15 +0200

Same here.

From: Txauth <[email-masked]> on behalf of Adrian Hope-Bailie <[email-masked]>
Date: Saturday, January 11, 2020 at 09:11
To: Dick Hardt <[email-masked]>
Cc: <[email-masked]>, Justin Richer <[email-masked]>
Subject: Re: [Txauth] alternative charter writeup

+1

ᐧ

Hey

Key ideas:

/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..

 

ᐧ

-- 

-- Txauth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth

---

From: Lee McGovern <[email-masked]>
Date: Mon, 13 Jan 2020 07:59:20 +0000

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

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

From: Adrian Hope-Bailie <[email-masked]>
Sent: Samstag, 11. Januar 2020 08:11
To: Dick Hardt <[email-masked]>
Cc: Justin Richer <[email-masked]>; [email-masked]
Subject: Re: [Txauth] alternative charter writeup

+1

On Sat, Jan 11, 2020 at 04:56 Dick Hardt <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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:

On Jan 10, 2020, at 12:04 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hey

Key ideas:

/Dick

----

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

--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jan 2020 12:29:47 -0500

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 <[email-masked]> wrote:
> 
> On Sat, Jan 11, 2020 at 04:56 Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Jan 10, 2020, at 12:04 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hey
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>  
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jan 2020 09:53:00 -0800

UX constrained devices?

On Mon, Jan 13, 2020 at 9:30 AM Justin Richer <[email-masked]> 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.
>
> *From:* Adrian Hope-Bailie <[email-masked]>
> *Sent:* Samstag, 11. Januar 2020 08:11
> *To:* Dick Hardt <[email-masked]>
> *Cc:* Justin Richer <[email-masked]>; [email-masked]
> *Subject:* Re: [Txauth] alternative charter writeup
>
> +1
>
> 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.
> 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
> [email-masked]

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 13 Jan 2020 23:37:56 +0000

While I agree with the goals stated in this charter, if I read this from the perspective of someone who hasn’t been our meetings or listened to Justin’s presentations, I’m hard pressed to see what the point of this group is, relative to the OAuth WG. I’d expect this charter to provide at least a cursory explanation of what problem it is trying to solve. In this case, the problem should be partially defined in relation to OAuth. What will this WG do that the OAuth WG hasn’t already done or isn’t already doing?

How about adding something like the following to paragraph 2:

The protocol will mitigate many of the security concerns and technical challenges of OAuth 2.0 by communicating over secure channels between the client and the authorization server, and minimizing the amount of information transmitted over untrusted channels.

–
Annabelle Richard Backman
AWS Identity

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Friday, January 10, 2020 at 6:57 PM
To: Justin Richer <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] alternative charter writeup

Hey

Key ideas:

/Dick

----

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jan 2020 16:34:18 -0800

I agree, some more "why" would help a broader audience understand the
motivations. How about this change to the first paragraph?

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, an
extension of OAuth 2.0. In contrast to OAuth 2.0, 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, which will mitigate many of the security concerns and
technical challenges of OAuth 2.0.

On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> While I agree with the goals stated in this charter, if I read this from
> the perspective of someone who hasn’t been our meetings or listened to
> Justin’s presentations, I’m hard pressed to see what the point of this
> group is, relative to the OAuth WG. I’d expect this charter to provide at
> least a cursory explanation of what problem it is trying to solve. In this
> case, the problem should be partially defined in relation to OAuth. What
> will this WG do that the OAuth WG hasn’t already done or isn’t already
> doing?
>
>
>
> The protocol will mitigate many of the security concerns and technical
> challenges of OAuth 2.0 by communicating over secure channels between the
> client and the authorization server, and minimizing the amount of
> information transmitted over untrusted channels.
>
>
>
> –
>
> *From: *Txauth <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Friday, January 10, 2020 at 6:57 PM
> *To: *Justin Richer <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Txauth] alternative charter writeup
>
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 14 Jan 2020 01:54:57 +0000

It’s not just about the initial communication, though. I the key thing to emphasize is the decoupling the protocol from delegation channels, which addresses the aforementioned security/complexity issues and also provides a path to support future delegation channel types without significant changes to the protocol (unlike OAuth 2.0, where extensions like Device Flow and PAR introduce substantial changes to the core protocol flow on both client and AS). Since the protocol isn’t assuming a particular front channel, it’s easier to add support for a new one.

Proposal, altered from Dick’s suggestion:
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, an extension of OAuth 2.0. This protocol will be decoupled from delegation channels such as an end user’s web browser and operate primarily through a channel between the client and the authorization server, avoiding many of the security concerns and technical challenges of OAuth 2.0 and providing a non-invasive path for adding support for future types of clients and delegation channels.

–

From: Dick Hardt <[email-masked]>
Date: Monday, January 13, 2020 at 4:35 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] alternative charter writeup

I agree, some more "why" would help a broader audience understand the motivations. How about this change to the first paragraph?

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, an extension of OAuth 2.0. In contrast to OAuth 2.0, 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, which will mitigate many of the security concerns and technical challenges of OAuth 2.0.

On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
While I agree with the goals stated in this charter, if I read this from the perspective of someone who hasn’t been our meetings or listened to Justin’s presentations, I’m hard pressed to see what the point of this group is, relative to the OAuth WG. I’d expect this charter to provide at least a cursory explanation of what problem it is trying to solve. In this case, the problem should be partially defined in relation to OAuth. What will this WG do that the OAuth WG hasn’t already done or isn’t already doing?

–

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 10, 2020 at 6:57 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] alternative charter writeup

Hey

Key ideas:

/Dick

----

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jan 2020 21:24:10 -0500

I can get behind this kind of addition. I like Annabelle’s framing of it in terms of decoupling, and some explanation of why we’re doing it in relation to OAuth 2’s approach. One of the key things, to me, is that we’re making a break from OAuth 2’s core architecture but doing so for very specific reasons. 

 — Justin

> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> To: Justin Richer <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jan 2020 21:12:02 -0800

Sounds good to me.

On Mon, Jan 13, 2020 at 6:24 PM Justin Richer <[email-masked]> wrote:

> I can get behind this kind of addition. I like Annabelle’s framing of it
> in terms of decoupling, and some explanation of why we’re doing it in
> relation to OAuth 2’s approach. One of the key things, to me, is that we’re
> making a break from OAuth 2’s core architecture but doing so for very
> specific reasons.
>
>  — Justin
>
> It’s not just about the initial communication, though. I the key thing to
> emphasize is the decoupling the protocol from delegation channels, which
> addresses the aforementioned security/complexity issues and also provides a
> path to support future delegation channel types without significant changes
> to the protocol (unlike OAuth 2.0, where extensions like Device Flow and
> PAR introduce substantial changes to the core protocol flow on both client
> and AS). Since the protocol isn’t assuming a particular front channel, it’s
> easier to add support for a new one.
>
> extension of OAuth 2.0. This protocol will be decoupled from delegation
> channels such as an end user’s web browser and operate primarily through a
> channel between the client and the authorization server, avoiding many of
> the security concerns and technical challenges of OAuth 2.0 and providing a
> non-invasive path for adding support for future types of clients and
> delegation channels.
>
> –
> *From: *Dick Hardt <[email-masked]>
> *Date: *Monday, January 13, 2020 at 4:35 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 10:45:10 -0500

Here’s my updated text incorporating the feedback so far:

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 (an extension of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.

The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and 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. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 as well as providing a non-invasive path for supporting future types of clients and interaction channels.

- 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, interaction-constrained, and other types of client applications

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 where possible, and will strive to enable simple mapping to other protocols such as COAP.

It’s definitely a lot, but I think we’ve got a good handle on what we’re working on, and what the boundaries are. I think this is both too much of an effort and too much of a break to do this in the OAuth WG, where there’s already still plenty of work to be done. We’re leaning a lot on lessons learned from the OAuth 2 world and its extensions, including OIDC and UMA2. We’ve got the attention of a lot of the right people to start this as well.

So to the AD’s: Ben and Roman — what’s the next step? This should be a new working group and like to get it started so that we can have our first meeting in Vancouver.

 — Justin

> On Jan 14, 2020, at 12:12 AM, Dick Hardt <[email-masked]> wrote:
> 
> Sounds good to me.
> 
> On Mon, Jan 13, 2020 at 6:24 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>> Cc: Justin Richer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jan 2020 17:15:08 +0100

> Am 16.01.2020 um 16:45 schrieb Justin Richer <[email-masked]>:
> 

This sounds a bit incomplete to me. I assume the user would approve „the attestation of identity claims“. I furthermore think the user would approve „access to multiple APIs“. I would prefer API over resource because it is more universal. For example, the protocol could also be used to create resources.

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 16 Jan 2020 11:43:11 -0500

>>> - Delegation between multiple users

What does this mean exactly?

Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...)

Or does it only the "1-hop" delegation concurrently (Alice to Bob; Alice to Charlize; Alice to...)

-- thomas --

-----Original Message-----
From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Thursday, January 16, 2020 at 10:46 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Benjamin Kaduk <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Txauth] alternative charter writeup

 — Justin

Sounds good to me.

 — Justin

 
 
– 

 
On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <[email-masked]> wrote:

 
 
– 

ᐧ

Hey

Key ideas:

/Dick

----

 

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 11:51:18 -0500

> This sounds a bit incomplete to me. I assume the user would approve „the attestation of identity claims“. I furthermore think the user would approve „access to multiple APIs“. I would prefer API ov…

Point taken, but this isn’t meant to be an exhaustive list of what it can do, merely the list of things we’re positive we want it to do. I also prefer “API” over “resource”, but concede that “resource” can be a writeable thing too. Even then I’m happy to tweak the language here. 

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 11:53:25 -0500

On Jan 16, 2020, at 11:43 AM, Thomas Hardjono <[email-masked]> wrote:
> Or does it only the "1-hop" delegation concurrently (Alice to Bob; Alice to Charlize; Alice to…)

My thinking was that at the very least we want to allow the person running the client software and the person doing the authorization to be different people. This is the UMA use case (Alice to bob) and the CIBA use case (agent getting someone to log in). I think chaining can follow that, where Bob can then let Charlie do something. This is also along the lines of the token exchange model of OAuth 2, with continuously down-scoped access.

What I think is very much out of scope is cross-domain policy processing. 

 — Justin

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 16 Jan 2020 19:12:33 +0000

The only reason I can think of to single out identity within the charter is if there is some work or feature that is within scope for the working group, but only for identity claims (e.g., returning identity claims from the transaction endpoint). Repeating a question I posed earlier, what is it about identity claims that make them worthy of special consideration?

– 

On 1/16/20, 8:51 AM, "Justin Richer" <[email-masked]> wrote:

    
     — Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 15:58:26 -0500

I think that’s exactly the reason — the case of getting information about the user directly from the TX endpoint is well established. People don’t want to make another round trip just to figure out who’s there, when a lot of time that’s the first thing they care about, and then the’d make the determination of whether to follow other APIs after that. 

So if I can send you a very basic set of authn info from the callback, like an identifier and VoT style login information, then you can figure out if you need to know more about that user or not. But these basic claims do get elevated to the same level as other returned artifacts from the transaction, like the access tokens.

 — Justin

> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <[email-masked]> wrote:
>

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 16 Jan 2020 16:07:28 -0500

The problem is that the word "delegation" is generally a very loaded term.

I understand that WGs need wiggle room, but I'm concerned that this kind of loose wording may cause confusion down the road.

>> What I think is very much out of scope is cross-domain policy processing.

Agree.

-----Original Message-----
From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Thursday, January 16, 2020 at 11:54 AM
To: Thomas Hardjono <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] alternative charter writeup

 — Justin

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 16 Jan 2020 22:29:24 +0000

The same could be said for any resource, particularly in scenarios where the interaction was kicked off so that the SP can perform a specific action initiated by the user (e.g., charging a credit card or account, publishing a message to a message board or social media feed, retrieving a specific document or image).

Consider a flow like the following:
1. The end user is on a client website that provides a photo printing service, clicks the "Print from CloudStorageProvider" button.
4. The client initates TxAuth via CloudStorageProvider's transaction endpoint, requesting a URL for a photo to be selected by the end user.
5. CloudStorageProvider returns an interact_url pointing to its AS.
6. The client redirects the user agent to the AS.
7. The end user signs in, and selects the photo they want to print, and confirms authorization to share with the client.
8. The AS redirects the user agent back to client.
9. The client calls back to CloudStorageProvider's transaction endpoint to continue the TxAuth transaction.
10. CloudStorageProvider returns confirmation that the authorization was granted, along with the URL for the selected photo.

This is identical to the identity use case, we've just replaced identity claims with a URL to a photo. I see a lot of value in encouraging one-time authorization of specific actions like this, and if we're going to support inlining of resources for identity claims anyway, it's not a big stretch to allow for arbitrary resource types. I do think it's fair to narrowly scope the kinds of resource *schemas* the WG will define (e.g., defining core identity claims like OIDC did), but the inlining mechanism should be flexible (e.g., not limiting this to claims about the end user identity, like OIDC did).

– 

On 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" <[email-masked] on behalf of [email-masked]> wrote:

    
     — Justin

---

From: Dick Hardt <[email-masked]>
Date: Thu, 16 Jan 2020 14:31:17 -0800

I think of the resource as a container that has certain capabilities. An
early use case for delegation was for access to Flickr photos. Write access
to upload new photos was a capability.

An example of a resource without an API is where the client is also the
resource, and has delegated authorization to the AS. For example, you can
imagine a photo copier where you scan a QR code that send you to an AS that
then returns an artifact to the client how the user is authorized to use
the photo copier.
ᐧ

On Thu, Jan 16, 2020 at 8:15 AM Torsten Lodderstedt <[email-masked]>
wrote:

> This sounds a bit incomplete to me. I assume the user would approve „the
> attestation of identity claims“. I furthermore think the user would approve
> „access to multiple APIs“. I would prefer API over resource because it is
> more universal. For example, the protocol could also be used to create
> resources.

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 17:49:47 -0500

I’m cautiously Ok with having resource inlining be in scope — IF we can generalize it from the identity case specifically.

To do what you’re asking for though, the WG can still be chartered to solve identity (which we know is a well-established and understood use case), but also allow other things. 

This gets back to a fundamental question that I don’t have a clear answer for yet: what do you get back at the end of a transaction? Right now we’ve got a clear call for three things:

1. Access tokens to call APIs
2. Transaction handles to continue the transaction later (like a refresh token but better)
3. User identity claims

Maybe the mechanism we use for #3 can be generalized, or maybe there’s even a good way to provide switches for #1, #2, and #3. 

And while we’re on the topic of #3, I think there’s a strong case to be made that it should NOT be a user’s profile information, but rather just enough information to identify the user to the RP. If the RP wants to pull more profile info, it can do so via an API. This keeps us out of the anti-pattern that SAML has of always sending all claims about a user whether the RP needs them or not. But the RP will at least need to know if it has to request the claims, and we can do that by a simple enough structure like:

user: {
  “iss”: “http://foo.bar/“,
  “sub”: “12387yhjfre”,
  “last_updated”: 54239084
}

You can add VoT and other things that can vary per-login here as well. But I shouldn’t be sending you the user’s name and address every time they log in — as an RP you only need to get that if it’s a new account or if it’s been updated since you last saw it. You can’t handle that if you’re pushing all the claims in the response: Since the RP doesn’t know who the user is until after this stage, it can’t tell that information to the IdP ahead of time and therefore the IdP is forced to always send it just in case the RP might need it. But by telling the RP an identifier for the user and a tag of when any of their information was last updated I can make the decision whether or not to pull information at the RP in an intelligent fashion if I want to.

 — Justin

> On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 17:50:34 -0500

I get that, but that’s why the proposed charter text tries to be very explicit about who is delegating to whom (or what) and for what purpose. That’s why delegation to software and delegation between users are both listed separately. 

 — Justin

> On Jan 16, 2020, at 4:07 PM, Thomas Hardjono <[email-masked]> wrote:
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 16 Jan 2020 15:00:04 -0800

I was thinking that other kinds of delegation results would be yet another
top level request, and matching response. Since it is not a widely deployed
use case today, it would be an extension to the core protocol.

Justin:  What to you mean by VoT?

wrt. returning claims, vs access to claims, I think it is an important
discussion -- but let's put a pin in that for discussion in the WG once we
are formed! I don't think that needs to be in the charter, but happy to be
convinced otherwise.
ᐧ

On Thu, Jan 16, 2020 at 2:49 PM Justin Richer <[email-masked]> wrote:

> I’m cautiously Ok with having resource inlining be in scope — IF we can
> generalize it from the identity case specifically.
>
> To do what you’re asking for though, the WG can still be chartered to
> solve identity (which we know is a well-established and understood use
> case), but also allow other things.
>
> This gets back to a fundamental question that I don’t have a clear answer
> for yet: what do you get back at the end of a transaction? Right now we’ve
> got a clear call for three things:
>
> Maybe the mechanism we use for #3 can be generalized, or maybe there’s
> even a good way to provide switches for #1, #2, and #3.
>
> And while we’re on the topic of #3, I think there’s a strong case to be
> made that it should NOT be a user’s profile information, but rather just
> enough information to identify the user to the RP. If the RP wants to pull
> more profile info, it can do so via an API. This keeps us out of the
> anti-pattern that SAML has of always sending all claims about a user
> whether the RP needs them or not. But the RP will at least need to know if
> it has to request the claims, and we can do that by a simple enough
> structure like:
>
> user: {
> You can add VoT and other things that can vary per-login here as well. But
> I shouldn’t be sending you the user’s name and address every time they log
> in — as an RP you only need to get that if it’s a new account or if it’s
> been updated since you last saw it. You can’t handle that if you’re pushing
> all the claims in the response: Since the RP doesn’t know who the user is
> until after this stage, it can’t tell that information to the IdP ahead of
> time and therefore the IdP is forced to always send it just in case the RP
> might need it. But by telling the RP an identifier for the user and a tag
> of when any of their information was last updated I can make the decision
> whether or not to pull information at the RP in an intelligent fashion if I
> want to.
>
>  — Justin
>
> > The same could be said for any resource, particularly in scenarios where
> the interaction was kicked off so that the SP can perform a specific action
> initiated by the user (e.g., charging a credit card or account, publishing
> a message to a message board or social media feed, retrieving a specific
> document or image).
> >
> > 1. The end user is on a client website that provides a photo printing
> service, clicks the "Print from CloudStorageProvider" button.
> > 4. The client initates TxAuth via CloudStorageProvider's transaction
> endpoint, requesting a URL for a photo to be selected by the end user.
> > 7. The end user signs in, and selects the photo they want to print, and
> confirms authorization to share with the client.
> > 10. CloudStorageProvider returns confirmation that the authorization was
> granted, along with the URL for the selected photo.
> >
> > This is identical to the identity use case, we've just replaced identity
> claims with a URL to a photo. I see a lot of value in encouraging one-time
> authorization of specific actions like this, and if we're going to support
> inlining of resources for identity claims anyway, it's not a big stretch to
> allow for arbitrary resource types. I do think it's fair to narrowly scope
> the kinds of resource *schemas* the WG will define (e.g., defining core
> identity claims like OIDC did), but the inlining mechanism should be
> flexible (e.g., not limiting this to claims about the end user identity,
> like OIDC did).
> >
> > –
> > On 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >    I think that’s exactly the reason — the case of getting information
> about the user directly from the TX endpoint is well established. People
> don’t want to make another round trip just to figure out who’s there, when
> a lot of time that’s the first thing they care about, and then the’d make
> the determination of whether to follow other APIs after that.
> >
> >    So if I can send you a very basic set of authn info from the
> callback, like an identifier and VoT style login information, then you can
> figure out if you need to know more about that user or not. But these basic
> claims do get elevated to the same level as other returned artifacts from
> the transaction, like the access tokens.
> >
> >     — Justin
> >
> >> The only reason I can think of to single out identity within the
> charter is if there is some work or feature that is within scope for the
> working group, but only for identity claims (e.g., returning identity
> claims from the transaction endpoint). Repeating a question I posed
> earlier, what is it about identity claims that make them worthy of special
> consideration?
> >>
> >> –
> >>> This sounds a bit incomplete to me. I assume the user would approve
> „the attestation of identity claims“. I furthermore think the user would
> approve „access to multiple APIs“. I would prefer API over resource because
> it is more universal. For example, the protocol could also be used to
> create resources.
> >>
> >>   Point taken, but this isn’t meant to be an exhaustive list of what it
> can do, merely the list of things we’re positive we want it to do. I also
> prefer “API” over “resource”, but concede that “resource” can be a
> writeable thing too. Even then I’m happy to tweak the language here.
> >>
> >>    — Justin
> >>
> >
> >    --
> >    Txauth mailing list
> >    [email-masked]

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 16 Jan 2020 18:16:32 -0500

Yes, I see that sentence ("This protocol will allow an authorizing party to delegate access to client software through an authorization server"). That's very specific, which is good.

Just wanted to be sure that the bullet further below ("Delegation between multiple users") also makes sense given that the first sentence is talking about delegation to a piece of software.

It’s a big jump between (i) a person delegating to a piece of software, to (ii) a person delegating to another person.

Sorry for being pedantic.

-- thomas --

-----Original Message-----
From: Justin Richer <[email-masked]>
Date: Thursday, January 16, 2020 at 5:50 PM
To: Thomas Hardjono <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] alternative charter writeup

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Thu, 16 Jan 2020 15:21:25 -0800

What I have understood we are enabling is a separation between the user
using the client software, and the user that is the resource owner.

Justin: is that what you had in mind?
ᐧ

On Thu, Jan 16, 2020 at 3:17 PM Thomas Hardjono <[email-masked]>
wrote:

> Yes, I see that sentence ("This protocol will allow an authorizing party
> to delegate access to client software through an authorization server").
> That's very specific, which is good.
>
> Just wanted to be sure that the bullet further below ("Delegation between
> multiple users") also makes sense given that the first sentence is talking
> about delegation to a piece of software.
>
> It’s a big jump between (i) a person delegating to a piece of software, to
> (ii) a person delegating to another person.
>
> I get that, but that’s why the proposed charter text tries to be very
> explicit about who is delegating to whom (or what) and for what purpose.
> That’s why delegation to software and delegation between users are both
> listed separately.
>
>  — Justin
>
> > I understand that WGs need wiggle room, but I'm concerned that this kind
> of loose wording may cause confusion down the road.
> >
> >
> >
> > My thinking was that at the very least we want to allow the person
> running the client software and the person doing the authorization to be
> different people. This is the UMA use case (Alice to bob) and the CIBA use
> case (agent getting someone to log in). I think chaining can follow that,
> where Bob can then let Charlie do something. This is also along the lines
> of the token exchange model of OAuth 2, with continuously down-scoped
> access.
> >
> >> Cc: "[email-masked]" <[email-masked]>, "Richard Backman, Annabelle" <
> [email-masked]>, Benjamin Kaduk <[email-masked]>, Dick Hardt <
> [email-masked]>
> deployed use cases currently supported by OAuth 2.0 and OpenID Connect (an
> extension of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
> >>
> >>
> protocol, each performing a specific role. The protocol will decouple the
> interaction channels, such as the end user’s browser, from the delegation
> channel, which happens directly between the client and 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. This decoupling avoids many of the security concerns and
> technical challenges of OAuth 2.0 as well as providing a non-invasive path
> for supporting future types of clients and interaction channels.
> >>
> >>
> >> - Mechanisms for providing user, software, organization, and other
> pieces of information used in authorization decisions
> >>
> 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 where
> possible, and will strive to enable simple mapping to other protocols such
> as COAP.
> >>
> >>
> >>
> >>
> >>
> >> It’s definitely a lot, but I think we’ve got a good handle on what
> we’re working on, and what the boundaries are. I think this is both too
> much of an effort and too much of a break to do this in the OAuth WG, where
> there’s already still plenty of work to be done. We’re leaning a lot on
> lessons learned from the OAuth 2 world and its extensions, including OIDC
> and UMA2. We’ve got the attention of a lot of the right people to start
> this as well.
> >>
> >> So to the AD’s: Ben and Roman — what’s the next step? This should be a
> new working group and like to get it started so that we can have our first
> meeting in Vancouver.
> >>
> >> — Justin
> >>
> >>
> >> I can get behind this kind of addition. I like Annabelle’s framing of
> it in terms of decoupling, and some explanation of why we’re doing it in
> >> It’s not just about the initial communication, though. I the key thing
> to emphasize is the decoupling the protocol from delegation channels, which
> >> 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, an extension of OAuth 2.0. This protocol will be decoupled
> from delegation channels such as an end user’s web browser and operate
> primarily through a channel between the client and the authorization
> server, avoiding many of the security concerns and technical challenges of
> OAuth 2.0 and providing a non-invasive path for adding support for future
> types of clients and delegation channels.
> >>
> >> –
> >> Cc: Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]
> >
> >> 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, an extension of OAuth 2.0. In contrast to OAuth 2.0, 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, which will mitigate
> many of the security concerns and technical challenges of OAuth 2.0.
> >>
> >>
> >>
> >>
> >>
> >> While I agree with the goals stated in this charter, if I read this
> from the perspective of someone who hasn’t been our meetings or listened to
> >> 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:
> >>
> >>
> >>
> >> - Mechanisms for providing user, software, organization, and other
> pieces of information used in authorization decisions
> >>
> 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.
> >>
> >>
> >>
> >>
> >>
> >> 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..
> >>
> >>
> >> 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
> >> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jan 2020 08:46:32 -0500

So really we’re talking about “delegating to a piece of software that someone else is using” when we say “delegation between multiple users”. 

Is there a better or more succinct way to put that in the charter text? Really we want the RO/RqP separation that UMA gives us explicitly to be an option here, and I think it naturally can be given our structure.

 — Justin

> On Jan 16, 2020, at 6:16 PM, Thomas Hardjono <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jan 2020 08:46:49 -0500

Yes, this.

> On Jan 16, 2020, at 6:21 PM, Dick Hardt <[email-masked]> wrote:
> 
> What I have understood we are enabling is a separation between the user using the client software, and the user that is the resource owner. 
> 
> On Thu, Jan 16, 2020 at 3:17 PM Thomas Hardjono <[email-masked] <mailto:[email-masked]>> wrote:
> From: Justin Richer <[email-masked] <mailto:[email-masked]>>
> To: Thomas Hardjono <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> > On Jan 16, 2020, at 4:07 PM, Thomas Hardjono <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Justin Richer <[email-masked] <mailto:[email-masked]>>
> > To: Thomas Hardjono <[email-masked] <mailto:[email-masked]>>
> > Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> > On Jan 16, 2020, at 11:43 AM, Thomas Hardjono <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> 
> >> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Justin Richer <[email-masked] <mailto:[email-masked]>>
> >> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> >> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>, Dick Hardt <[email-masked] <mailto:[email-masked]>>
> >> On Jan 14, 2020, at 12:12 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> Sounds good to me.
> >>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jan 2020 08:49:15 -0500

I’m thinking this as well — I think it’s the kind of detail that the WG can sort out, and that’s what I mean by figuring out a way to generalize my point #3 below into Annabelle’s use cases. I’m for figuring it out if we can do it, but not at the expense of what I’m seeing as a pretty clear set of semantics already. 

VoT == Vectors of Trust, RFC8485. A way to communicate information about the user logging in, basically authentication context but with more dimensions.

 — Justin

> On Jan 16, 2020, at 6:00 PM, Dick Hardt <[email-masked]> wrote:
> 
> I was thinking that other kinds of delegation results would be yet another top level request, and matching response. Since it is not a widely deployed use case today, it would be an extension to the core protocol.
> 
> wrt. returning claims, vs access to claims, I think it is an important discussion -- but let's put a pin in that for discussion in the WG once we are formed! I don't think that needs to be in the charter, but happy to be convinced otherwise. 
> ᐧ
> 
> On Thu, Jan 16, 2020 at 2:49 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>   “iss”: “http://foo.bar/ <http://foo.bar/>“,
>   “sub”: “12387yhjfre”,
>   “last_updated”: 54239084
> }
> 
> 
> > On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > On 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> On 1/16/20, 8:51 AM, "Justin Richer" <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >>   On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> 
> >>> 
> >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <[email-masked] <mailto:[email-masked]>>:
> >>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 17 Jan 2020 15:59:27 +0000

My experience is that people will stretch and comfort the semantics of “identity claims” to fit this use cases. I’m fine with deferring the discussion to the WG, provided that we agree the charter doesn’t rule out the possibility.

Sent from my iPhone

On Jan 17, 2020, at 5:49 AM, Justin Richer <[email-masked]> wrote:

 — Justin

On Jan 16, 2020, at 6:00 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

wrt. returning claims, vs access to claims, I think it is an important discussion -- but let's put a pin in that for discussion in the WG once we are formed! I don't think that needs to be in the charter, but happy to be convinced otherwise.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=b76c3490-3177-4d54-814e-946c84fd915b]ᐧ

On Thu, Jan 16, 2020 at 2:49 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I’m cautiously Ok with having resource inlining be in scope — IF we can generalize it from the identity case specifically.

user: {

 — Justin

> On Jan 16, 2020, at 5:29 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
>
> On 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> On 1/16/20, 8:51 AM, "Justin Richer" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>   On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <[email-masked]<mailto:[email-masked]>>:
>>>>

---

From: Justin Richer <[email-masked]>
Date: Sat, 18 Jan 2020 09:02:01 -0500

That’s a reasonable take, thanks for bringing up the discussion.

 — Justin

> On Jan 17, 2020, at 10:59 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>>> On Jan 16, 2020, at 6:00 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>>