Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 110

[Andre Triverio <[e-mail]>]

Allez-vous cesser de m'envoyer des mails !
Je n'en veux pas !
Et pour se desabonner, tout est fait pouir ne pas y réussir !

Le lun. 30 mars 2020 à 18:41, <[e-mail]> a écrit :

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. RAR - Example JWT for Payment (Jared Jennings)
>    2. Re: Error Responses in JWT Profile for OAuth 2.0 Access
>       Tokens (Karl McGuinness)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Mar 2020 08:18:49 -0500
> From: Jared Jennings <[e-mail]>
> To: oauth <[e-mail]>
> Subject: [OAUTH-WG] RAR - Example JWT for Payment
> Message-ID:
>         <
> [e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> I have a question about the example and maybe it's more for
> clarification than anything.
>
> The example contains type and also location.
> A couple of things
> 1. Would it add clarity if the domain was the same for both? vs.
> someorg.com
> / example.com
> 2. While only an example, would it bring clerity to past examples if the
> type was https://schema.example.com/payment_initiation and the location
> was
> https://api.example.com/payments
>
> or am I missing something what the values represent?
>
> Here's the example I am referring to on page 17.
>
> {
>       "iss": "https://as.example.com",
>       "sub": "24400320",
>       "aud": "a7AfcPcsl2",
>       "exp": 1311281970,
>       "acr": "psd2_sca",
>       "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
>       "authorization_details": [
>          {
>             "type": "https://www.someorg.com/payment_initiation",
>             "actions": [
>                "initiate",
>                "status",
>                "cancel"
>             ],
>             "locations": [
>                "https://example.com/payments"
>             ],
>             "instructedAmount": {
>                "currency": "EUR",
>                "amount": "123.50"
>             },
>             "creditorName": "Merchant123",
>             "creditorAccount": {
>                "iban": "DE02100100109307118603"
>             },
>             "remittanceInformationUnstructured": "Ref Number Merchant"
>          }
>       ],
>       "debtorAccount": {
>          "iban": "DE40100100103307118608",
>          "user_role": "owner"
>       }
>    ]
>
>
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: [phone]
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/cdb44a38/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Mar 2020 16:38:04 +0000
> From: Karl McGuinness <[e-mail]>
> To: "vittorio.bertocci=[e-mail]"
>         <vittorio.bertocci=[e-mail]>
> Cc: Aaron Parecki <[e-mail]>, OAuth WG <[e-mail]>
> Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0
>         Access Tokens
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Vittorio,
>
> I was chatting with Aaron offline about this issue and my concern is the
> addition of Authentication Information Claims in this spec opens up more
> interoperability issues that can?t be addressed with just a JWT Access
> Token spec.
>
> OAuth 2.0 AFAIK, doesn?t define any behaviors around resource owner
> authentication assurance with respect to issuing, introspecting, or
> presenting access tokens.
>
>   *   Token introspection
>   *   Token validation error responses
>   *   Token refresh
>   *   Client Remediation (oidc defined prompt=login, max_age, and
> acr_values)
>   *   Metadata
>
> This spec is defining AS behaviors that are orthogonal to the format and
> should be available via token introspection for example
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-2.2.1
>
>
> The claims listed in this section reflect in the access token the the
>    types and strength of authentication that the authentication server
>    enforced prior to returning the authorization response to the client.
>    Their values are fixed, and remain the same across all access tokens
>    that derive from a given authorization response, whether the access
>    token was obtained directly in the response (e.g., via the implicit
>    flow) or after one or more token exchanges (e.g., obtaining a fresh
>    access token using a refresh token, or exchanging one access token
>    for another via [RFC8693<https://tools.ietf.org/html/rfc8693>]
>
>
> I was hoping one of the outcomes of this spec was toolkit/sdk interop for
> clients and resource servers.   I don?t see how this possible if all the
> semantics around requesting, validating, and remediating resource owner
> authentication assurance is implementation specific.   The end-to-end
> scenarios are not achievable with just OAuth 2.0 which breaks interop.
>
> I think there is a real need to define resource owner authentication
> assurance interoperability for access tokens, but I fear this may require
> its own spec.
>
> -Karl
>
> Karl McGuinness
> Chief Product Architect
> www.okta.com<http://www.okta.com/>
>
> On Mar 25, 2020, at 12:59 PM, vittorio.bertocci=[e-mail]
> <mailto:vittorio.bertocci=[e-mail]> wrote:
>
> This message originated outside your organization.
>
> Thanks Aaron!
> You are right, we could be clearer re:errors. AFAIK the only errors we can
> rely on from an RS are in RFC6750, and the entire section is about what to
> look for in an incoming AT to validate, hence it doesn't look like we have
> much choice but to return invalid_token for every error in the validation
> checks enumerated in Section 4. I can definitely add a paragraph to that
> effect (does it have to be a section?).
>
> The re-authentication part is tricky. Technically we are still rejecting
> the
> incoming token, hence the above should still apply.
> I am not aware of tools we can use from the primitives defined in the
> OAuth2
> family of standards for telling people how to make reauthentication happen-
> and making reauth happen can be quite involved. In Azure AD there are semi
> proprietary mechanisms that can be used to signal the need to repeat
> authentication, say for triggering a step-up auth, by sending back together
> with the error response a challenge that can in turn be used by the client
> to communicate policy requirements to the AS (which is assumed to support
> OIDC and accept/understand those policies in form of claim). Giving
> equivalent guidance but relying only on standards seems tricky, especially
> without making strong assumptions about how auth happens (e.g can we assume
> OIDC?).
> To solve this for the profile, I see two main ways forward:
> A) We warn the reader that it's on them to decide how to signal the reauth
> requirement from the API to the client, and how to use that in the client
> to
> AS subsequent authorization request
> B) We venture in devising a standard mechanism for propagating errors that
> require reauth, basically extending RFC6750 with a new use case (perhaps by
> detailing extra info to be put in WWW-Authenticate?).
>
> I can see how B) might be useful in general, but it doesn't seem
> particularly tied to the fact that the ATs being discussed here are JWTs...
> hence I'd be inclined to declare it out of scope here, tho I would really
> love for us to devise a standard solution for it _somewhere_.
> WDYT?
>
>
>
> -----Original Message-----
> From: OAuth <[e-mail]<mailto:[e-mail]>> On
> Behalf Of Aaron Parecki
> Sent: Wednesday, March 25, 2020 12:07 PM
> To: OAuth WG <[e-mail]<mailto:[e-mail]>>
> Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access
> Tokens
>
> Section 4 talks about validating JWT Access Tokens
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-4
>
> It has a list of things the RS MUST do when validating a request made with
> a
> JWT access token. This section contains phrases like "...and reject
> tokens..." and "MUST be rejected if...", without clear instructions on
> *how*
> to reject this request. For these, I could infer that the RFC6750 error
> code
> "invalid_token" is the correct response, but these could benefit from being
> more explicit about that here.
>
> Step 7 says:  "the resource server SHOULD check the auth_time value and
> request re-authentication..." But there are no instructions on how the RS
> should respond to indicate that the client should request
> re-authentication.
> This sounds like a different response than "invalid_token" to me, but in
> any
> case, regardless of what the correct response is, Section 4 really needs a
> description of how to respond in these error cases.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/6db2d3fd/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 137, Issue 110
> ***************************************
>


-- 
André Triverio, CJM