[Openid-specs-authzen] Open issues and PRs

Tue Aug 19 09:28:35 UTC 2025

Already fixed it: https://github.com/openid/authzen/pull/356

On Tue, Aug 19, 2025 at 11:27 AM Lombardo, Jeff <jeffsec at amazon.com> wrote:

> I know where it is.
>
>
>
> Leave me 5 minutes.
>
>
>
> *Jean-François “Jeff” Lombardo* | Amazon Web Services
>
>
>
> Architecte Principal de Solutions, Spécialiste de Sécurité
> Principal Solution Architect, Security Specialist
> Montréal, Canada
>
> ( +1 514 778 5565
>
> *Commentaires à propos de notre échange? **Exprimez-vous **ici*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *Thoughts on our interaction? Provide feedback **here*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *From:* David Brossard <david.brossard at gmail.com>
> *Sent:* August 19, 2025 11:24 AM
> *To:* Lombardo, Jeff <jeffsec at amazon.com>
> *Cc:* AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
> *Subject:* RE: [EXT] [Openid-specs-authzen] Open issues and PRs
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur
> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous
> ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas
> certain que le contenu ne présente aucun risque.
>
>
>
> I'll have to check the metadata section - we have a duplicate HTML anchor
> ID which is breaking the build process.
>
>
>
> /home/runner/work/authzen/authzen/api/authorization-api-1_0.xml(2033):
> Warning: Duplicate xsd:ID attribute anchor="iana-wk-registry" found.  This
> will cause validation failure.
> api/authorization-api-1_0.xml(2033): Error: Invalid attribute anchor for
> element section, at /rfc/middle/section[14]/section[3]
> /home/runner/work/authzen/authzen/api/authorization-api-1_0.xml(15):
> Error: Invalid document before running preptool.
> Unable to complete processing api/authorization-api-1_0.xml
> Error: Process completed with exit code 1.
>
>
>
> On Tue, Aug 19, 2025 at 11:13 AM Lombardo, Jeff <jeffsec at amazon.com>
> wrote:
>
> Hi,
>
>
>
> I took action on the two items under my name:
>
>    - Gerry will check the status of issue 300
>    <https://github.com/openid/authzen/issues/300>. Jeff L., you were
>    working on it.
>
>
>    - Updated the proposal for metadata
>       - Pushed a new PR:
>
>
>    - Decision: Preserved the usage of the iss metadata document parameter.
>
>
>    - Rationale:
>
>
>    - iss is only required is signature of metadata is enforced by the PDP
>                - Preserving the same taxonomy allows convergence with
>                OAuth2 Protected Resource Metadata RFC
>                - iss (issuer) is pointing to the entity ensuring the
>                metadata anti-tampering protection by exposing the JWKS there. While the
>                iss might point to the PDP server itself, it is not
>                mandatory as the function of acting as PDP and signing metadata can be
>                provided by two different components
>                - Therefore iss does not provide any confusion with the
>                notion of PDP even if coming from the OAuth2 world
>                - Doing otherwise would have AuthZEN having to declare new
>                attribute to IANA
>
>
>    - Added the capabilities metadata document field
>          - Added the declaration of the associated IANA registry
>
>
>    - Jeff, we need clarification on issue 268
>    <https://github.com/openid/authzen/issues/268> re. authentication.
>
>
>    - While it was pretty clear from the beginning that this was not a
>       proposal to make authentication mandatory, I added a new statement in #268
>       and the associated PR
>       - To answer the comments:
>
>
>    - Realm is notion defined by HTTP when using a response header of
>          format WWW-Authenticate. There is nothing new, nothing fancy.
>          - There is no typo (double checked with 2 other spelling tools)
>          - the only MUST is that a 401 has to be returned
>          - Any other information is covered by a SHOULD already
>          - If one does not one authentication, then the initial if makes
>          it sure that the conditions does not apply cause, when no authentication is
>          required, there are no ways you can provide a bad credential, a bad
>          authentication scheme, nor a bad authentication proof.
>
>
>    - Still the text as been updated to:
>
> If the protected resource request does not include the *proper* authentication
> credentials, does not contain an the proper the correct authentication
> scheme, or does not have a valid authentication scheme proof that enables
> access to the protected resource, the resource server MUST respond with a
> 401 HTTP code and SHOULD include the HTTP "WWW-Authenticate" response
> header field; it MAY include it in response to other conditions as well.
> The "WWW-Authenticate" header field uses the framework defined by HTTP/1.1
> [RFC2617] and indicate the expected auth-scheme as long as the realm that
> has authority for it.
>
>
>
> Jeff
>
>
>
> *Jean-François “Jeff” Lombardo* | Amazon Web Services
>
>
>
> Architecte Principal de Solutions, Spécialiste de Sécurité
> Principal Solution Architect, Security Specialist
> Montréal, Canada
>
> ( +1 514 778 5565
>
> *Commentaires à propos de notre échange? **Exprimez-vous **ici*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *Thoughts on our interaction? Provide feedback **here*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *From:* Openid-specs-authzen <
> openid-specs-authzen-bounces at lists.openid.net> *On Behalf Of *David
> Brossard via Openid-specs-authzen
> *Sent:* August 19, 2025 9:59 AM
> *To:* AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
> *Cc:* David Brossard <david.brossard at gmail.com>
> *Subject:* [EXT] [Openid-specs-authzen] Open issues and PRs
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur
> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous
> ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas
> certain que le contenu ne présente aucun risque.
>
>
>
> Dear all,
>
>
>
> We still have 11 issues <https://github.com/openid/authzen/issues/> and 2 pull
> requests <https://github.com/openid/authzen/pulls> open on the
> specification draft. In order to move forward to final spec, we need to
> close these out.
>
>
>
>    - Issue 352 (Michiel) deals with normative HTTP binding paths. I
>    remember early on Omri wanting to formalize the structure of the URLs
>    (/access/v1/evaluation) but the current draft
>    <https://openid.github.io/authzen/> doesn't make any mention of
>    mandatory or normative URLs. In addition, the fact we introduced the
>    metadata endpoint negates the need for normative URLs formats. The only
>    necessary endpoint becomes the metadata endpoint. Given this, Michiel
>    pointed out (and I agree) we probably need to make the metadata endpoint
>    mandatory to be conformant. Today, it's optional.
>
>
>    - If there are no objections, we will therefore close this issue i.e.
>       not make any runtime paths normative
>       - We will make the metadata API path normative
>       - We will make the metadata API mandatory
>
>
>    - Issue 339 is easy to fix: we write 4-tuple in cases when in fact it
>    can be a 3-tuple or an n-tuple. We should just reword to avoid a specific
>    number. I assigned Alex but he's on PTO. Any takers for the fix?
>    - Issue 325 <https://github.com/openid/authzen/issues/325> is
>    outstanding. It has to do with pagination methods. It needs to be wrapped
>
>
>    - Also, pagination is defined in no less than 3 sections (8.3.1,
>       9.3.1, and 10.3.1). They need to be abstracted away. We will use the same
>       pagination method for all API endpoints so no need to rewrite 3 times and
>       risk inconsistencies. Alex B., you were working on this. Do you have time
>       to fix it?
>
>
>    - Gerry will check the status of issue 300
>    <https://github.com/openid/authzen/issues/300>. Jeff L., you were
>    working on it.
>    - Jeff, we need clarification on issue 268
>    <https://github.com/openid/authzen/issues/268> re. authentication.
>    - We need to agree to punt issue 250
>    <https://github.com/openid/authzen/issues/250> to after the 1.0 spec.
>    Or punt the entire Evaluations semantics to after 1.0
>    -  Issues 230 <https://github.com/openid/authzen/issues/230>and 229
>    need work. Roland, this was your baby. We can choose to punt it to after
>    1.0 as well.
>    - Issue 55 <https://github.com/openid/authzen/issues/55>: Elie, can
>    you add a proposal?
>    - Issue 47 <https://github.com/openid/authzen/issues/47> should be
>    rejected given the extensive rewrites
>    - The same applies to 46.
>
>
>
> Thanks all for reading,
>
> David
>
>
>
> --
>
> ---
> David Brossard
> http://www.linkedin.com/in/davidbrossard
> http://twitter.com/davidjbrossard
> http://about.me/brossard
> ---
> Stay safe on the Internet: IC3 Prevention Tips
> <https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
> Prenez vos précautions sur Internet:
> https://cyber.gouv.fr/bonnes-pratiques-protegez-vous
>
>
>
>
> --
>
> ---
> David Brossard
> http://www.linkedin.com/in/davidbrossard
> http://twitter.com/davidjbrossard
> http://about.me/brossard
> ---
> Stay safe on the Internet: IC3 Prevention Tips
> <https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
> Prenez vos précautions sur Internet:
> https://cyber.gouv.fr/bonnes-pratiques-protegez-vous
>

-- 
---
David Brossard
http://www.linkedin.com/in/davidbrossard
http://twitter.com/davidjbrossard
http://about.me/brossard
---
Stay safe on the Internet: IC3 Prevention Tips
<https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
Prenez vos précautions sur Internet:
https://cyber.gouv.fr/bonnes-pratiques-protegez-vous
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250819/f3a9a904/attachment-0001.htm>