Messages - 2.1.2.1 'acr' value 'MAY' seems wrong
Issue #848
resolved
Currently, it says:
An absolute URI or a registered name [RFC6711] MAY be used as an acr value.
This allows someone to define a duplicative short name to RFC6711 and use it, which causes both security and interoperability issues.
Proposal:
An absolute URI or a registered name [RFC6711] MUST be used as an acr value.
Comments (3)
-
-
-
assigned issue to
John wrote: "That is OK, I don't think it requires run time checking of the registry, it is more a rule that can be used in disputes on what is correct."
Nat wrote: "Ok with 3). You need to record this thread to the ticket though. Just a copy and paste would do."
-
assigned issue to
-
- changed status to resolved
Fixed
#848- 'acr' value 'MAY' seems wrong→ <<cset 39bbe43777e1>>
- Log in to comment
I could live with this:
An absolute URI or a <xref target="RFC6711">registered name</xref> SHOULD be used as an <spanx style="verb">acr</spanx> value; registered names MUST NOT be used with a different meaning than that which is registered.
The principle is the same as that which allows private claims names in JWT section 4.3, even though we're talking about claim values, rather than claim names. Normally, registered or collision-resistant names should be used. But “between consenting implementations”, there’s nothing wrong with using private names, any more than there is anything wrong with using private claim names. Yes collisions could eventually result. But that’s the risk that people using private names are knowingly taking.
If we weren’t in a space-constrained environment, I wouldn’t have any problem with a MUST. But we are, so brevity is essential, and absolute URIs are far from brief. We should therefore never have a MUST that effectively requires their use.