[Openid-specs-ab] Spec Call Notes 11-Jan-24
George Fletcher
george.fletcher at capitalone.com
Thu Jan 11 20:20:36 UTC 2024
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240111/23e20af1/attachment-0001.html>
More information about the Openid-specs-ab
mailing list