Re: [Txauth] alternative charter writeup

[Dick Hardt <[e-mail]>]

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]> 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/“,
>   “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]> 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] on behalf of [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]> 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]> wrote:
> >>
> >>   On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <
> [e-mail]> wrote:
> >>>
> >>>
> >>>
> >>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <[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]
> >    https://www.ietf.org/mailman/listinfo/txauth
> >
> >
>
>