3.1.   Categorization of the specs

The group discussed and agreed that there are legitimate case of starting with QR code as a part of discovery and do the usual redirect flow instead of CIBA.

Thus, the group agreed that it would be creating two set of specs:

• CIBA Core + CIBA FAPI profile
• Discovery standard

CIBA Core + CIBA FAPI profile is time critical while the Discovery is not, thus the group will first work on the former.

3.2.   CIBA Core Issues (Brian)

Brian explained the problems existing in the CIBA Core right now per his email. To sum up, there are many inconsistencies and cannot be reliably implemented. E.g.,

• Endpoint needs to be fixed.
• Client authentication

There was an observation by John that much of the inconsistency actually stems from the symmetric authentication needs. If these parts were separated out and if the core just talks about the asymmetric authentication, it will become much simpler and more consistent.

The group agreed to remove the symmetric option from this document, I.e., move to another MODRNA specific document.

Who is going to file the proposal to MODRNA WG?

3.3.   Structured Login Token (Ralph)

Ralph expressed the needs for a Structured Login Token that indicates the identifier type. Perhaps it can be done by introducing structure to Login_hint_token.

John explained that the reason for login hint token in Modrna was to blind the RP. This was important for MNOs.

However, in the financial institution side, there are cases where you are required to share a static identifier, Ralph explained.

There are other problems in the Login hint token. For instance, CIBA Core states Login hint MUST be validated. This actually does not work.

JSON Login Hint

ID Token Hint : No Validation. One can if wanted.

Extend the login token hint to allow multiple types.

Pull the construct from MODRNA Discovery to CIBA, generalize.

JWT in JWT.

{

• type:
• value:

}

Login hint token subject type in the Server Metadata: IANA registry

First define in CIBA.