Re: [Txauth] alternative charter writeup

[Justin Richer <[e-mail]>]

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

 — Justin

> On Jan 17, 2020, at 10:59 AM, Richard Backman, Annabelle <[e-mail]> wrote:
> 
> 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 <[e-mail]> wrote:
>> 
>>  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 <[e-mail] <mailto:[e-mail]>> 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.
>>> 
>>> 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 <[e-mail] <mailto:[e-mail]>> 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:
>>> 
>>> 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/ <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 <[e-mail] <mailto:[e-mail]>> wrote:
>>> > 
>>> > 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).
>>> > 
>>> > – 
>>> > Annabelle Richard Backman
>>> > AWS Identity
>>> > 
>>> > 
>>> > On 1/16/20, 12:59 PM, "Txauth on behalf of Justin Richer" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> 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
>>> > 
>>> >> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> 
>>> >> 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?
>>> >> 
>>> >> – 
>>> >> Annabelle Richard Backman
>>> >> AWS Identity
>>> >> 
>>> >> 
>>> >> On 1/16/20, 8:51 AM, "Justin Richer" <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> 
>>> >>   On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <[e-mail] <mailto:[e-mail]>> wrote:
>>> >>> 
>>> >>> 
>>> >>> 
>>> >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <[e-mail] <mailto:[e-mail]>>:
>>> >>>> 
>>> >>>> - Approval of identity claims and multiple resources in a single interaction
>>> >>> 
>>> >>> 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
>>> >    [e-mail] <mailto:[e-mail]>
>>> >    https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> > 
>>> > 
>>> 
>> 
>> -- 
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth