[Openid-specs-ab] FW: OpenID Connect A/B Call Meeting Notes - 30th August 2022
Mike Jones
Michael.Jones at microsoft.com
Tue Aug 30 18:34:33 UTC 2022
Thanks to Karthik for taking notes yesterday!
From: Karthik Sivasamy <karthik.sivasamy at mattr.global>
Sent: Monday, August 29, 2022 5:59 PM
To: Mike Jones <Michael.Jones at microsoft.com>
Subject: OpenID Connect A/B Call Meeting Notes - 30th August 2022
Hi Mike,
As promised, Please find below the meeting notes that I recorded during our OIDC A/B Call today (30th August 2022 New Zealand Time).
Hopefully this helps.
Regards,
Karthik
Date: 30th August 30, 2022 (New Zealand Standard Time)
Attendees:
* Mike Jones
* Vittorio
* Nat
* Karthik
* Dima
* Tobias
* Guiseppe De Marco
* Tom Jones
* John Bradley
PR - 286 (https://bitbucket.org/openid/connect/pull-requests/286)
* Tobias -
* This pattern can lead to double up to get the same information
* Mike
* If you are in multi-party federation, this is the way of RP saying I want to be part of the federation request
* In the Italian federation, they found this pattern useful architecturally
* 3 approval received so far for the PR
* Tobias - Concern
* There could be inconsistency
* Mike - willing to hold this open if Tobias wants to actively review the PR
* Tobias thinks there is general utility for automatic registration wider than the federation scenarios - so there is a benefit in seeing with that lens
* Giuseppe:
unfortunately I can't speak because too late in italy and I'm sacrified in a little house in the mountains and everybody sleep right now.
well, thank you mike for the explanation. The hinted trust chain pushes a signal that an already cached EC by a OP is changed, and the RP let the OP knows this to get its EC be updated to the OP (hopefully, it's an hint)
* Tobias is less concerned if it is signal or hint
* Action - Mike requested Tobias to review by Thursday
PR - 289 (https://bitbucket.org/openid/connect/pull-requests/289)
* Describing the differences between automatic and explicit registration
* Kristina requested for Tobias to review - Mike to see whether he can add Tobias as an approver
* Tobias - Comparison should not be just with dynamic registration, but also with pre-registration client via out-of-band process
* ACTION - Tobias to review this PR
Issue 1606 - https://bitbucket.org/openid/connect/issues/1606/relax-behaviour-around-automatic-client
* Mike - This issue took half the time on federation call on Friday
* Giuseppe was in the favor of relaxation. Mike asked John to look at It and John looked at the issue in the call
* There is a Distinction in the use-cases - What we want from federation vs general
* For Federation - John pointed out - the entire ecosystem needs to establish trust between participants. This is due to legal reasons (not just for protocol messaging)
* E.g. Edugain - code of conduct and trust across the ecosystem
* If you have a client that you can't clearly identify , then there is a inherent risk
* For federation use-cases we want to keep it as is - but we could add a note for other use cases, you could forego the requirement of signed request
* Tobias - If redirect URI used by the client is http based and OP trusts the redirect URI
* We do have a trust on redirect URI and somehow we can identify the client using that
* Signed request object is one way to identify the client
* Automatic registration can be done without signed request object
* We could separate out both
* If we are going to reference federation spec for other use-cases, we want a more clear direction in the spec than a note in the specification
* We want implementers to understand the differences and implication
* We are talking about a new way of registering client
* Mike to think about this scenario seriously
* Wants more than automatic registration
* Tobias - Why do we need entity statement. Client may reference their metadata in the published URI ( that may also include entity statement )
* John Bradley did a version of this ten years ago without a traction in OAuth working Group
* ACTION - Mike to think about the language in which it was written and whether we can rewrite in a approachable language
* Tobias - I am not suggesting any normative changes to the Federation spec
Mike - Nat filed a number of issues. Let us look at it
* Kristina - mainly editorial
* Nat - started reviewing the document and mostly editorial stuff. E.g. consistent capitalization, etc..
* New Grant Type discussion (pre-authorized code flow)
* Kristina
* Client can take the pre-authorised code to the token endpoint which can't be satisfied with any existing grant type
* So we created a new grant type - that is the rational
* NAT - to look closely into the spec
* Can be a nightmare from security point of view
* Vittorio
* That sounds like a regression and agreeing with Nat's views (Custom pre-authorization code flow in general )
* Nat - the fact that it talks straight to token endpoint is concerning from security point of view
* TL - There are multiple ways we can secure pre-authorized code flow (client authentication)
* ACTION - Nat and Vittorio to relook at this
PR - 293 https://bitbucket.org/openid/connect/pull-requests/293Kristina - Discussing /<https://bitbucket.org/openid/connect/pull-requests/293Kristina%20-%20Discussing%20/>
(Decoupling proof and key attestation)
* Three big changes
* Separated attestation from the binding method
* Replace Proof with binding_method (happy to reword)
* Defined attestation
* Guiseppe reviewed - x5c claim required
* John Bradley
* Google has 2 attestation formats
* Android key store attestation only says something about the key
* Tobias - Android safety net uses android key attestation
* They are for different purposes but has relationship at a low level
* Google has said that they will be changing it.
* Has suspicion that RP is going to have hard time with 32 different formats & methods
* RP with WebAuthn has hard time with attestationformats
* TL - What constitutes an attestation format ?
* what constitutes an attestation format: data representation (jwt, cwt)? Is X.509 too broad?
* Is x509 format or android safety net or JWT or cwt
* Android key store and attestation uses its own exotic format
* John
* You can sign a JWT and CBOR and include that in the certificate
* There is some sort of root key needed to be validated to provide attestation - the actual attestation is not a x509 certificate
* Say you are using a YubiKey - RP will ask for compact attestation where the key has x509 certificate (batch key)
* Essentially as JWT is created signed by the secret key
* Certificate for that key is signed by the Public key and goes to RP
* RP can look at the key and find the root for that certificate
* The thing that signed the public key is being attested when walking back
* Tobias - there are also attestation formats that is a chain of x509
* In Android key store - attestation format was x509
* What is the attestation format - is it going to mirror cwt or jwt or lower level detail?
* Tobias - Key attestation in android is x509
* John - The bottom line is RPs are not equipped to deal with the complexity to verify the attestation mechanism
* TL - big question is - Where do we draw the boundary on attestation formats vs options that exists with attestation formats (is x509 too broad)?
* John - Create an object that has a byte strings (similar to webauthn)
* TL - Less ideal but probably a reality.
* John - things are going to change constantly (google relooking attestation formats).
* essentially make an IANA registry for the format and leave it to RP.
* John - whether the issuer is going to trust the key attestation or wallet provider ?
* Kristina -
* Considering there is no standard way to put the attestation information, how do we approach?
* John - Create an attestation container that has:
* Format id - jwt (android safetynet), tpm , andorid key store,
* Type - android safetynet
* Byte string - having raw attestation
* ACTION - Kristina to update the PR with this information
* Guiseppe - considering that the Provider may be able to add additional information, more than the app attestation API does ... for instance a wallet unique ID (different from the provider/backend client_id)
Kristina - requesting John's opinion on single credential endpoint vs batch credential issuance
* Kristina - we also had separate endpoint called deferred credential endpoint:
* There is an implementation feedback questioning the value of this endpoint
* Editors thinking to repurpose simple and batch endpoints to include deferred credential scenarios
* John - on the phase of it polling can be complicated due to DDoS
* E.g CIBA
* This sounds like the problems we looked at CIBA
* In FAPI, we have scenarios where we start the transaction and it can't be completed which required similar approach - but this will open a can of worms
* Introducing delayed mechanisms will push people to ask more features similar to this which can get quite complex to achieve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220830/17a5996b/attachment.html>
More information about the Openid-specs-ab
mailing list