[OAUTH-WG] Help

[Vanessa Andor <[e-mail]>]

On Mon, Sep 2, 2019, 5:45 PM <[e-mail]> wrote:

> 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. . ?ric Vyncke's No Objection on?????
>       draft-ietf-oauth-resource-indicators-05: (nessandorae)
>    2. Benjamin Kaduk's Discuss on
>       draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and
>       COMMENT) (Benjamin Kaduk via Datatracker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 02 Sep 2019 15:20:54 -0500
> From: nessandorae <[e-mail]>
> To: [e-mail]
> Subject: [OAUTH-WG] . ?ric Vyncke's No Objection on?????
>         draft-ietf-oauth-resource-indicators-05:
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> google.comSent from my MetroPCS 4G LTE Android Device
> -------- Original message --------From: [e-mail] Date:
> 9/2/19  2:00 PM  (GMT-06:00) To: [e-mail] Subject: OAuth Digest,
> Vol 131, Issue 2 Send OAuth mailing list submissions to     [e-mail]
> subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauthor, via email, send a message
> with subject or body 'help' to [e-mail] can reach the
> person managing the list at     [e-mail] replying, please
> edit your Subject line so it is more specificthan "Re: Contents of OAuth
> digest..."Today's Topics:?? 1. ?ric Vyncke's No Objection on?????
> draft-ietf-oauth-resource-indicators-05: (with COMMENT)????? (?ric Vyncke
> via Datatracker)?? 2. Re:? ?ric Vyncke's No Objection on?????
> draft-ietf-oauth-resource-indicators-05: (with COMMENT) (ki de)?? 3. Fwd:
> New Version Notification for????? draft-yusef-oauth-nested-jwt-02.txt
> (Rifaat
> Shekh-Yusef)----------------------------------------------------------------------Message
>  : 1Date: Mon, 02 Sep 2019 02:40:31 -0700From: ?ric Vyncke via Datatracker
> <[e-mail]>To: "The IESG" <[e-mail]>Cc:
> [e-mail], Rifaat Shekh-Yusef        <
> [e-mail]>, [e-mail], [e-mail],
> [e-mail]: [OAUTH-WG] ?ric Vyncke's No Objection on
> draft-ietf-oauth-resource-indicators-05: (with COMMENT)Message-ID:      <
> [e-mail]>Content-Type:
> text/plain; charset="utf-8"?ric Vyncke has entered the following ballot
> position fordraft-ietf-oauth-resource-indicators-05: No ObjectionWhen
> responding, please keep the subject line intact and reply to allemail
> addresses included in the To and CC lines. (Feel free to cut
> thisintroductory paragraph, however.)Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more
> information about IESG DISCUSS and COMMENT positions.The document, along
> with other ballot positions, can be found here:https://data
>
> tracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/----------------------------------------------------------------------COMMENT:----------------------------------------------------------------------Thank
> you for the hard work put into this easy to read document.Regards,-?ric==
> COMMENTS ==-- Section 1 --"has uncovered a need, in some circumstances"
> (and similar sentences in section1), it is rather vague for a standard
> track document... Please add some factsand data, this could be a companion
> document about requirements/use cases.-- Section 2 --It is rather a
> question of mine, why does the resource need to be a URI (whichusually
> bears some visible semantics) rather than an opaque string known onlyby the
> resource owner/server ? This is similar to Mirja's comment about
> privacy.------------------------------Message: 2Date: Mon, 2 Sep 2019
> 10:22:53 +0000From: ki de <[e-mail]>To: ?ric Vyncke <
> [e-mail]>Cc: The IESG <[e-mail]>,
> "draft-ietf-oauth-resource-ind
>  [e-mail]"      <[e-mail]>, "
> [e-mail]"       <[e-mail]>, "[e-mail]" <
> [e-mail]>Subject: Re: [OAUTH-WG]? ?ric Vyncke's No Objection
> on draft-ietf-oauth-resource-indicators-05: (with COMMENT)Message-ID:      <
> [e-mail]>
>       Content-Type: text/plain; charset="utf-8"On Mon, Sep 2, 2019 at 5:40
> AM ?ric Vyncke via Datatracker <[e-mail]> wrote:?ric Vyncke has
> entered the following ballot position
> fordraft-ietf-oauth-resource-indicators-05: No ObjectionWhen responding,
> please keep the subject line intact and reply to allemail addresses
> included in the To and CC lines. (Feel free to cut thisintroductory
> paragraph, however.)Please refer to
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7
>  C637030140461915948&amp;sdata=sK56j9bwVyLlNupgEdxExdaBTTOLnI28%2FYSTJVgLpG4%3D&amp;reserved=0for
> more information about IESG DISCUSS and COMMENT positions.The document,
> along with other ballot positions, can be found here:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-resource-indicators%2F&amp;data=02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637030140461925959&amp;sdata=yGz0cyRb7FgYxHtHOMLTScZeIpTSQGb7pu6NOhQF2Ic%3D&amp;reserved=0----------------------------------------------------------------------COMMENT:----------------------------------------------------------------------Thank
> you for the hard work put into this easy to read document.Regards,-?ric==
> COMMENTS ==-- Section 1 --"has uncovered a need, in some circumstances"
> (and similar sentences in section1), it is rather vague for a standard
> track document... Please add some factsand data, this could be a companion
> docu
>  ment about requirements/use cases.-- Section 2 --It is rather a question
> of mine, why does the resource need to be a URI (whichusually bears some
> visible semantics) rather than an opaque string known onlyby the resource
> owner/server ? This is similar to Mirja's comment about
> privacy._______________________________________________OAuth mailing
> [e-mail]://
> nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637030140461925959&amp;sdata=QfcbDqqJ9Z6g%2BLq8dNAAizQcLfpLxR543GBaqZwiAsw%3D&amp;reserved=0--------------
> next part --------------An HTML attachment was scrubbed...URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902/3f1a298a/attachment.html>------------------------------Message:
> 3Date: Mon, 2 Sep 2019 11:03:20 -0400From: Rifaat Shekh-Yusef <
> [e-mail]>To: oauth <[e-mail]>Subject: [OA
>  UTH-WG] Fwd: New Version Notification for
> draft-yusef-oauth-nested-jwt-02.txtMessage-ID:  <
> [e-mail]>Content-Type:
> text/plain; charset="utf-8"All,I have submitted a new version of the Nested
> JWT draft and added the STIRuse case.Please, take a look and let me know if
> you have any comments.Regards, Rifaat---------- Forwarded message
> ---------From: <[e-mail]>Date: Mon, Sep 2, 2019 at 10:59
> AMSubject: New Version Notification for
> draft-yusef-oauth-nested-jwt-02.txtTo: Rifaat Shekh-Yusef <
> [e-mail]>A new version of I-D,
> draft-yusef-oauth-nested-jwt-02.txthas been successfully submitted by
> Rifaat Shekh-Yusef and posted to theIETF repository.Name:??????????
> draft-yusef-oauth-nested-jwtRevision:?????? 02Title:????????? Nested JSON
> Web Token (JWT)Document date:? 2019-09-02Group:????????? Individual
> SubmissionPages:????????? 5URL:
> https://www.ietf.org/internet-drafts/draft-yusef-oauth-nested-jwt-02.txtStatus:ht
>  tps://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/Htmlized:??????
>
> https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-02Htmlized:https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwtDiff:https://www.ietf.org/rfcdiff?url2=draft-yusef-oauth-nested-jwt-02Abstract:??
> This specification extends the scope of the Nested JSON Web Token?? (JWT)
> to allow the enclosing JWT to contain its own Claims Set in?? addition to
> the enclosed JWT.Please note that it may take a couple of minutes from the
> time of submissionuntil the htmlized version and diff are available at
> tools.ietf.org.The IETF Secretariat-------------- next part
> --------------An HTML attachment was scrubbed...URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902/1c70a6df/attachment.html>------------------------------Subject:
> Digest Footer_______________________________________________OAuth mailing
> [e-mail]://
> www.ietf.org/mailman/listinfo/oauth------------------------------
>  End of OAuth Digest, Vol 131, Issue 2*************************************
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190902/91be47b2/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 02 Sep 2019 15:44:27 -0700
> From: Benjamin Kaduk via Datatracker <[e-mail]>
> To: "The IESG" <[e-mail]>
> Cc: [e-mail], Rifaat
>         Shekh-Yusef <[e-mail]>, [e-mail],
>         [e-mail], [e-mail]
> Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on
>         draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and
>         COMMENT)
> Message-ID:
>         <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-jwt-introspection-response-07: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Per the ongoing discussion on the WG list, it's unclear that we can
> retain the behaviors we describe and still comply with the requirements
> of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat",
> etc.).  That is, in the present formulation, there are two "token"s
> involved -- the input that is being introspected, and the "token" that
> is the introspection response.  We are claiming that certain fields are
> describing the input token, when they are defined to be statements about
> the current (response) token.
> Relaxing our statements to say that we merely use JWS as opposed to JWT
> may be a workaround, though I have thought about it hard enough to have
> an opinion on whether it is the best workaround.
>
> I also think we need more clarity about the use of dynamic client
> registration by a resource server as outlined in Section 4 (where it's
> mentioned as "with a resource server posing as the client", without
> reference to RFC 7591.  As far as I can tell this document/section is
> introducing this use of dynamic client registration by an RS for the
> first time, so we cannot easily just refer to some other document.
> Specifically, are there any fields that MUST NOT be supplied?  Is a
> human-readable client_name useful?  How does the supplied client_uri
> need to relate to any existing AS representation of a resource in
> audience, scope, etc. (e.g., for the "resource" request parameter from
> draft-ietf-oauth-resource-indicators)?
>
> Is this usage considered to be a "new use of JWTs"?  If so, it seems
> that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and
> use explicit typing.
>
> I think there are some missing links in the document between a RS
> registring client policy and the resulting AS enforcement of encryption
> of introspection reponses.  I think the intent is roughly that the
> policy will be applied based on the audience of the token being
> presented for introspection (as opposed to the identity of the
> RS-as-client making the introspection request), but we don't seem to
> explicitly say that.  Also, we'd need to say something about the
> interaction of multiple RSs' policy when a given token has multiple
> valid audiences.  There is a very brief discussion in Section 6.5, but
> it seems to be more of a description of what is possible than mandating
> particular forms of enforcement.
>
> I think we should discuss whether we want some statement from the OpenID
> Foundation or related bodies before we register claims that point to
> their documents with the IESG listed as change controller.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> idnits notes that RFC 5646 is mentioned but not present in the
> references section.
>
> Section 1
>
> We probably need to move the 7519 reference up here to where JWT is
> first used.
>
>    OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
>    protected resource to query an OAuth 2.0 authorization server to
>    determine the state of an access token and obtain data associated
>    with the access token.  This allows deployments to implement
>    identifier-based access tokens in an interoperable way.
>
> Does "identifier-based access tokens" mean "tokens that are opaque keys
> to a (central) database lookup" or "access tokens that convey user
> identity information" (or something else)?  We may want to tweak the
> wording.
>
> Section 3
>
> Can we double-check the base64 form of the response in this example?  I
> am seeing output that backslash-escapes the '/' characters in URLs,
> which I did not think was needed in this context.
> I also see an "extension_field" claim in the base64 but not the decoded
> form of the example, and "given_name"/"family_name"/"birthdate" in the
> decoded example vs. "username" in the base64 version.
>
>    Note: If the resource server policy requires a signed and encrypted
>    response and the authorization server receives an unauthenticated
>    request containing an Accept header with content type other than
>    "application/jwt", it MUST refuse to serve the request and return an
>    HTTP status code 400.  This is done to prevent downgrading attacks to
>    obtain token data intended for release to legitimate recipients only
>    (see Section 6.2).
>
> I'd suggest a forward-reference to section 4 for how the AS will know
> the RS's policy.  Although, given that "unauthenticated request" is
> included in the preconditions, perhaps we do not need the conditional on
> "resource server policy" at all?
>
> Section 4
>
>    The authorization server determines what algorithm to employ to
>    secure the JWT for a particular introspection response.  This
>    decision can be based on registered metadata parameters for the
>    resource server, supplied via dynamic client registration with the
>    resource server posing as the client, as defined by this draft.
>
> nit: I suggest s/posing as the/acting as a/, and s/by this draft/below/,
> since it's right here in this section.
>
>    introspection_encrypted_response_alg  OPTIONAL.  JWE [RFC7516]
>            algorithm ("alg" value) as defined in JWA [RFC7518] for
>            encrypting introspection responses.  If this is specified,
>            the response will be encrypted using JWE and the configured
>            algorithm.  The default, if omitted, is that no encryption is
>
> This text is slightly confusing with respect to the interaction between
> the introspection_encrypted_response_alg "alg" value and the
> introspection_encrypted_response_enc "enc" value.  My understanding is
> that the "enc" is a symmetric bulk encryption scheme that directly
> protects the payload, whereas the "alg" is a key-wrap or key-agreement
> mechanism used to establish the key used as input for the "enc" method.
> So, while "algorithm ("alg value") for encrypting introspection
> responses" and "the response will be encrypted using the confugred
> ["algo"] algorithm" are technically true, they're also a bit misleading,
> since this is not what encrypts the "bulk" of the response.  Using the
> term from RFC 7158, "key management algorithm", would probably alleviate
> this confusion.
>
>    Resource servers may register their public encryption keys using the
>    "jwks_uri" or "jwks" metadata parameters.
>
> Should we cite 7591 for these (or, really, the whole section)?  We don't
> currently mention it until the IANA considerations.
>
> Section 5
>
> Is it worth a note that resource servers will fetch these metadata and
> use them as input to their dynamic registrations in the previous section
> (i.e., picking from the list of supported algorithms)?
>
>    introspection_encryption_alg_values_supported  OPTIONAL.  JSON array
>            containing a list of the JWE [RFC7516] encryption algorithms
>            ("alg" values) as defined in JWA [RFC7518] supported by the
>            introspection endpoint to encrypt the response.
>
> Similarly to the above, some refined text about "key management
> algorithm" used to encrypt the response, would probably be helpful.
>
> Section 6
>
> There seem to be notable privacy considerations about quite a few of the
> claims registered in Section 8.3.
>
> Section 6.1
>
> I'm surprised to not see discussion of explicit typing (and, IIUC, how
> it's not a reliable mitigation) here.
>
>    JWT introspection responses and OpenID Connect ID Tokens are
>    syntactically similar.  An attacker could therefore attempt to
>    impersonate an end-user at a OpenID Connect relying party by passing
>    the JWT as an ID token.
>
> nit: "response JWT" or "JWT response"
>
>    Such an attack can be prevented like any other token substitution
>    attack.  The authorization server MUST include the claims "iss" and
>    "aud" in each JWT introspection response, with the "iss" value set to
>    the authorization server's issuer URL and the "aud" value set to the
>    resource server's identifier.  [...]
>
> Related to the Discuss point, how does this relate to the dynamic client
> registration parameters?
>
>    [OpenID.Core].  Relying parties SHOULD also use and check the "nonce"
>    parameter and claim to prevent token and code replay.
>
> Is this SHOULD just referring to the behavior already described in
> OpenID.Core (and only applicable to OIDC implementations as opposed to
> JWT-instrospection consumers)?  If so, maybe descriptive language is
> more appropriate, like "Relying parties are also expected to use and
> check [...]".
>
>    Resource servers utilizing JWTs to represent self-contained access
>    tokens could be susceptible to replay attacks.  Resource servers
>    should therefore apply proper counter measures against replay as
>    described in [I-D.ietf-oauth-security-topics], section 2.2.
>
> I'm not sure what part of this is specific to the introspection case.
> Is it supposed to be tied to the risk that JWT-instrospection produces a
> new route for the generation of JWT objects that could be confused for
> self-contained access tokens?
> nit: "countermeasures" is valid as a single word.
> nit: it looks like it's section 3.2, now.
>
> Section 6.2
>
> Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP 195
> [RFC7525]").
>
>    To prevent introspection of leaked tokens and to present an
>    additional security layer against token guessing attacks the
>    authorization server may require all requests to the token
>    introspection endpoint to be authenticated.  As an alternative or as
>    an addition to the authentication, the intended recipients may be set
>    up for encrypted responses.
>
> Do we want to make either of these "may"s into normative recommendations
> (or make a recommendation for prevention of introspection data leakage
> even in the face of token leakage, which can be satisfied by either
> mechanism)?
>
> Also, we could say more about how configuring encryption for intended
> recipients protects against unencrypted replies to unintended
> recipients...
>
>    In the latter case, confidentiality is ensured by the fact that only
>    the legitimate recipient is able to decrypt the response.  An
>    attacker could try to circumvent this measure by requesting a plain
>    JSON response, using an Accept header with the content type set to,
>    for example, "application/json" instead of "application/jwt".  To
>    prevent this attack the authorization server MUST NOT serve requests
>    with content type other than "application/jwt" if the resource server
>    is set up to receive encrypted responses (see also Section 3).
>
> ....such as by saying that the introspection response will only be made
> available to RSes that are intended recipients of (in the audience of?)
> the access token being introspected.
>
> Section 6.3
>
>    Authorization servers with a policy that requires token data to be
>    kept confidential from OAuth clients must require all requests to the
>    token introspection endpoint to be authenticated.  As an alternative
>    or as an addition to the authentication, the intended recipients may
>    be set up for encrypted responses.
>
> [this also seems to be assuming a link not stated between RS policy and
> AS enforcement, but it seems unlikely that a fix would need to touch
> this text]
>
> Section 8.1.1
>
> nit: using nested lists might make this more readable.
>
>    o  Client Metadata Description: String value specifying the desired
>       introspection response encryption algorithm (alg value).
>
> [same bit about "key management algorithm"]
>
> Section 8.2.1
>
>    o  Metadata Description: JSON array containing a list of algorithms
>       supported by the authorization server for introspection response
>       encryption (alg value).
>
> [and here]
>
> Section 8.3
>
> I think we should make some mention earlier in the document
> (Introduction?) that we also register some common claim values that are
> in use in the wild (or whatever text you feel is appropriate to describe
> the claims in question).
>
> The nested lists would be great here as well.
>
> Is there any expectation that some combination of "given_name",
> "middle_name", and "family_name" will produce identical content to the
> full "name" claim?
>
>    o  Name: "preferred_username"
>
>    o  Description: Shorthand name by which the End-User wishes to be
>       referred to at the RP, such as janedoe or j.doe.  This value MAY
>       be any valid JSON string including special characters such as @,
>       /, or whitespace.
>
> It seems like there may be some security considerations about sanitziing
> this field before using it in an application's logic.
>
>    o  Name: "profile"
>
>    o  Description:URL of the End-User's profile page.  The contents of
>       this Web page SHOULD be about the End-User.
>
> It's slightly surpising to see this claimed for the end-user's profile
> when it might equally apply to a protocol profile or variant in use.
> But I assume this is already deployed, so there's no real point in
> objecting to its registration...
>
>    o  Name: "birthdate"
>
>    o  Description:Time the End-User's information was last updated.  Its
>       value is a JSON number representing the number of seconds from
>       1970-01-01T0:0:0Z as measured in UTC until the date/time.
>
> This seems potentially confusable with the user's day/year of birth.
> (Also, are leap seconds excluded?)
>
>    o  Name: "zoneinfo"
>
>    o  Description: String from zoneinfo [zoneinfo] time zone database
>       representing the End-User's time zone.  For example, Europe/Paris
>       or America/Los_Angeles.
>
> We seem to be missing the actual reference entry for [zoneinfo].
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 131, Issue 3
> *************************************
>