Re: [Txauth] alternative charter writeup

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" <txauth-bounces@ietf.org on behalf of jricher@mit.edu> 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 <richanna@amazon.com> 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" <jricher@mit.edu> wrote:
    > 
    >    On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    >> 
    >> 
    >> 
    >>> Am 16.01.2020 um 16:45 schrieb Justin Richer <jricher@mit.edu>:
    >>> 
    >>> - 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
    Txauth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth