[Openid-specs-ab] Spec Call Notes 11-Jan-24
Aaron Parecki
aaron at parecki.com
Thu Jan 11 23:29:56 UTC 2024
While we're at it, my name is spelled Parecki 😃
On Thu, Jan 11, 2024 at 12:21 PM George Fletcher via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> Reposting the notes with changes... with sincere apologies to Bjorn!
>
> Attendees
>
> -
>
> Mike Jones
> -
>
> David Chadwick
> -
>
> Pamela Dingle
> -
>
> Bjorn Hjelm
> -
>
> Aaron Pareki
> -
>
> George Fletcher
>
>
>
> Topics
>
> -
>
> Identity at the IETF - Pam
> -
>
> Two new working groups forming (spice and wimse)
> -
>
> The WHODIS effort has been shutdown
> -
>
> Huge amount of work in the OAuth working group
> -
>
> People trying to form new cells of people to do work
> -
>
> SPICE IETF WG
> -
>
> More churn around what the charter should be
> -
>
> High attendance at the last BoF
> -
>
> Low interaction on the mailing list
> -
>
> WIMSE IETF WG
> -
>
> Good momentum
> -
>
> Some healthy disagreement about goals
> -
>
> Working group will likely form
> -
>
> OpenID Connect - initial authorize call
> -
>
> Spec says authorization services must support a POST to the
> /authorization endpoint
> -
>
> Certification suite does not test for POST to the endpoint
> -
>
> 3.1.2.1 Authentication Request
> -
>
> 3.2.2.1 Authorization Request
> -
>
> HL7 FHIR spec also adopted the requirement to support POST
> -
>
> This is now federal law in the US -
> -
>
> Any AS who wants to support MUST support the POST HTTP Method
> -
>
> https://hl7.org/fhir/smart-app-launch/app-launch.html#request-4
> <https://urldefense.com/v3/__https://hl7.org/fhir/smart-app-launch/app-launch.html*request-4__;Iw!!FrPt2g6CO4Wadw!Oegf08haUVnG23qsEk0bkGXfpZvQ0nSbi85Rf7UT9QBSq60xON6OOETDXVIYfoZUBohzy4_qp3UbUMqUtWsdnA$>
> -
>
>
> https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program
> <https://urldefense.com/v3/__https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program__;!!FrPt2g6CO4Wadw!Oegf08haUVnG23qsEk0bkGXfpZvQ0nSbi85Rf7UT9QBSq60xON6OOETDXVIYfoZUBohzy4_qp3UbUMrCE0RC-A$>
> -
>
>
> https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and
> <https://urldefense.com/v3/__https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and__;!!FrPt2g6CO4Wadw!Oegf08haUVnG23qsEk0bkGXfpZvQ0nSbi85Rf7UT9QBSq60xON6OOETDXVIYfoZUBohzy4_qp3UbUMotD7Z6ag$>
> -
>
> Short term action - add a test for this to the certification suite
> -
>
> What does this mean for re-certification of Authorization Servers?
> -
>
> Always been a case that a certification is for a specific point
> in time
> -
>
> Entirely voluntary as to when systems decide to re-certify
> -
>
> Possible to blog about the addition of the test and its
> relevance to HL7 FHIR
> -
>
> The expectation is that most Authorization Servers are NOT
> supporting POST method at the /authorization endpoint
> -
>
> If an AS wanted this kind of feature, they probably implemented
> PAR rather than this solution
> -
>
> PAR provides some additional security benefits as well (over
> this method)
> -
>
> Recommendation: file an issue in the certification repository
> explaining the situation and that a test needs to be added
> -
>
> Send an email to the connect mailing list when the issue is filed
> -
>
> https://gitlab.com/openid/conformance-suite/
> <https://urldefense.com/v3/__https://gitlab.com/openid/conformance-suite/__;!!FrPt2g6CO4Wadw!N7hRzm4BUd--80Tmxd6QJpbpPstJewIAU-ebgROAQddLdbujOqQOxQK0RzIrXGiKfkhcFhy3uMQ5rZYBNaa_fWpgLsmC37jIWoM$>
>
> -
>
> Pam is sending out the min ACR protocol
> -
>
> Very low adoption of acr_values across the industry
> -
>
> Looking to be able to set a policy that is agnostic of protocol
> (SAML , OIDC)
> -
>
> Proposing a minimum interoperability profile to enable SAML and
> OIDC to process in a equivalent way
> -
>
> The biggest concern is that `acr_values` parameter is voluntary
> -
>
> Need acr values to be essential rather than voluntary
> -
>
> Plans to publish in the OpenID Connect working group (could also be
> published in the EAP working group)
> -
>
> Send proposal to both OpenID Connect and EAP working groups
> -
>
> https://github.com/pamelatech/ACRminprofile
> -
>
> From a principle perspective for OpenID Connect, there isn’t a
> requirement that the OP MUST follow the acr_values defined. However, the OP
> SHOULD return what it did perform.
> -
>
> There exists an error that identifies the OP didn’t do what’s
> requested in the acr_values
> -
>
> The goal is to be able to certify and enforce the desired behavior
> -
>
> Finding previous versions of OpenID Connect Core specification?
> -
>
> Links to previous versions located in the Introduction section of
> the core spec.
> -
>
> https://openid.net/specs/openid-connect-core-1_0.html#Introduction
> -
>
> Mike to update the guidance for working groups to comply with this
> process
> -
>
> Referencing previous versions in the Introduction section
> -
>
> Naming conventions can be found here:
> https://openid.net/wg/resources/naming-and-contents-of-specifications/
> -
>
> OpenID 4 Verifiable Credential Issuance - working to publish the first
> implementers draft
> -
>
> Discussed during the upcoming DCP working group call (11am EST 1/11)
> -
>
> Still an OpenID Connect working group spec
> -
>
> Issues
> -
>
> Issue #2101 – assigned to George Fletcher
> -
>
> George will look at the issue
>
>
>
> On Thu, Jan 11, 2024 at 11:25 AM George Fletcher <
> george.fletcher at capitalone.com> wrote:
>
>> A quick update... the WHODIS effort in the IETF has been officially shut
>> down
>>
>> On Thu, Jan 11, 2024 at 11:16 AM George Fletcher <
>> george.fletcher at capitalone.com> wrote:
>>
>>> Attendees
>>>
>>> -
>>>
>>> Mike Jones
>>> -
>>>
>>> David Chadwick
>>> -
>>>
>>> Pamela Dingle
>>> -
>>>
>>> Bjorn Helm
>>> -
>>>
>>> Aaron Pareki
>>> -
>>>
>>> George Fletcher
>>>
>>>
>>>
>>> Topics
>>>
>>> -
>>>
>>> Identity at the IETF - Pam
>>> -
>>>
>>> Two new working groups forming (spice and wimse)
>>> -
>>>
>>> Unclear where the IAB whodis effort is heading
>>> -
>>>
>>> Huge amount of work in the OAuth working group
>>> -
>>>
>>> People trying to form new cells of people to do work
>>> -
>>>
>>> SPICE IETF WG
>>> -
>>>
>>> More churn around what the charter should be
>>> -
>>>
>>> High attendance at the last BoF
>>> -
>>>
>>> Low interaction on the mailing list
>>> -
>>>
>>> WIMSE IETF WG
>>> -
>>>
>>> Good momentum
>>> -
>>>
>>> Some healthy disagreement about goals
>>> -
>>>
>>> Working group will likely form
>>> -
>>>
>>> OpenID Connect - initial authorize call
>>> -
>>>
>>> Spec says authorization services must support a POST to the
>>> /authorization endpoint
>>> -
>>>
>>> Certification suite does not test for POST to the endpoint
>>> -
>>>
>>> 3.1.2.1 Authentication Request
>>> -
>>>
>>> 3.2.2.1 Authorization Request
>>> -
>>>
>>> HL7 FHIR spec also adopted the requirement to support POST
>>> -
>>>
>>> This is now federal law in the US -
>>> -
>>>
>>> Any AS who wants to support MUST support the POST HTTP Method
>>> -
>>>
>>> https://hl7.org/fhir/smart-app-launch/app-launch.html#request-4
>>> <https://urldefense.com/v3/__https://hl7.org/fhir/smart-app-launch/app-launch.html*request-4__;Iw!!FrPt2g6CO4Wadw!Oegf08haUVnG23qsEk0bkGXfpZvQ0nSbi85Rf7UT9QBSq60xON6OOETDXVIYfoZUBohzy4_qp3UbUMqUtWsdnA$>
>>> -
>>>
>>>
>>> https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program
>>> <https://urldefense.com/v3/__https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program__;!!FrPt2g6CO4Wadw!Oegf08haUVnG23qsEk0bkGXfpZvQ0nSbi85Rf7UT9QBSq60xON6OOETDXVIYfoZUBohzy4_qp3UbUMrCE0RC-A$>
>>> -
>>>
>>>
>>> https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and
>>> <https://urldefense.com/v3/__https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and__;!!FrPt2g6CO4Wadw!Oegf08haUVnG23qsEk0bkGXfpZvQ0nSbi85Rf7UT9QBSq60xON6OOETDXVIYfoZUBohzy4_qp3UbUMotD7Z6ag$>
>>> -
>>>
>>> Short term action - add a test for this to the certification suite
>>> -
>>>
>>> What does this mean for re-certification of Authorization Servers?
>>> -
>>>
>>> Always been a case that a certification is for a specific
>>> point in time
>>> -
>>>
>>> Entirely voluntary as to when systems decide to re-certify
>>> -
>>>
>>> Possible to blog about the addition of the test and its
>>> relevance to HL7 FHIR
>>> -
>>>
>>> The expectation is that most Authorization Servers are NOT
>>> supporting POST method at the /authorization endpoint
>>> -
>>>
>>> If an AS wanted this kind of feature, they probably
>>> implemented PAR rather than this solution
>>> -
>>>
>>> PAR provides some additional security benefits as well (over
>>> this method)
>>> -
>>>
>>> Recommendation: file an issue in the certification repository
>>> explaining the situation and that a test needs to be added
>>> -
>>>
>>> Send an email to the connect mailing list when the issue is
>>> filed
>>> -
>>>
>>> https://gitlab.com/openid/conformance-suite/
>>> <https://urldefense.com/v3/__https://gitlab.com/openid/conformance-suite/__;!!FrPt2g6CO4Wadw!N7hRzm4BUd--80Tmxd6QJpbpPstJewIAU-ebgROAQddLdbujOqQOxQK0RzIrXGiKfkhcFhy3uMQ5rZYBNaa_fWpgLsmC37jIWoM$>
>>>
>>> -
>>>
>>> Pam is sending out the min ACR protocol
>>> -
>>>
>>> Very low adoption of acr_values across the industry
>>> -
>>>
>>> Looking to be able to set a policy that is agnostic of protocol
>>> (SAML , OIDC)
>>> -
>>>
>>> Proposing a minimum interoperability profile to enable SAML and
>>> OIDC to process in a equivalent way
>>> -
>>>
>>> The biggest concern is that `acr_values` parameter is voluntary
>>> -
>>>
>>> Need acr values to be essential rather than voluntary
>>> -
>>>
>>> Plans to publish in the OpenID Connect working group (could also
>>> be published in the EAP working group)
>>> -
>>>
>>> Send proposal to both OpenID Connect and EAP working groups
>>> -
>>>
>>> https://github.com/pamelatech/ACRminprofile
>>> -
>>>
>>> From a principle perspective for OpenID Connect, there isn’t a
>>> requirement that the OP MUST follow the acr_values defined. However, the OP
>>> SHOULD return what it did perform.
>>> -
>>>
>>> There exists an error that identifies the OP didn’t do what’s
>>> requested in the acr_values
>>> -
>>>
>>> The goal is to be able to certify and enforce the desired behavior
>>> -
>>>
>>> Finding previous versions of OpenID Connect Core specification?
>>> -
>>>
>>> Links to previous versions located in the Introduction section of
>>> the core spec.
>>> -
>>>
>>> https://openid.net/specs/openid-connect-core-1_0.html#Introduction
>>> -
>>>
>>> Mike to update the guidance for working groups to comply with this
>>> process
>>> -
>>>
>>> Referencing previous versions in the Introduction section
>>> -
>>>
>>> Naming conventions can be found here:
>>> https://openid.net/wg/resources/naming-and-contents-of-specifications/
>>> -
>>>
>>> OpenID 4 Verifiable Credential Issuance - working to publish the
>>> first implementers draft
>>> -
>>>
>>> Discussed during the upcoming DCP working group call (11am EST
>>> 1/11)
>>> -
>>>
>>> Still an OpenID Connect working group spec
>>> -
>>>
>>> Issues
>>> -
>>>
>>> Issue #2101 – assigned to George Fletcher
>>> -
>>>
>>> George will look at the issue
>>>
>>> ------------------------------
>
> The information contained in this e-mail may be confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240111/e07bd7fa/attachment-0001.html>
More information about the Openid-specs-ab
mailing list