[Openid-specs-ab] Spec Call Notes 26-Jun-23

Michael Jones michael_b_jones at hotmail.com
Tue Jun 27 00:20:14 UTC 2023


Spec Call Notes 26-Jun-23

Nat Sakimura
Giuseppe De Marco
Vittorio Bertocci
Mike Jones
Kosuke Koiwai
Naveen CM
David Waite
Edmund Jay
Dima Postnikov
Aaron Parecki

Events
              OAuth Security Workshop
                            https://oauth.secworkshop.events/osw2023
                           The workshop will be August 22-24 in London
                           The proposal submission deadline is Sunday, July 2
              IETF 117 San Francisco
                            https://www.ietf.org/how/meetings/117/
                           The draft submission deadline is Monday, July 10
              NIST is hosting a meeting about SP 800-63
                           https://www.nccoe.nist.gov/get-involved/attend-events/digital-identity-whats-next-nist
                           It is July 25-26 (overlapping IETF) in Washington DC and virtually

Display Types
              Mike published a call for adoption on June 12th, the deadline for which was today
              On the list, three people spoke in favor of adoption and Aaron Parecki opposed adoption
              On the call Vittorio said that he thought more motivation for the draft would be needed
                           Vittorio said that Facebook Connect used to have similar parameters, which could result in confusion
                           The user agent string and the parameter can provide conflicting information
                                         For instance, the display might be a TV or a mobile phone
              On the call, David Waite said that the only display value he's seen in the wild is "popup"
                           He said that we can already tell what kind of content to provide via the accept header
                           Vittorio said that "popup" has different security characteristics
              Kosuke said that he didn't have a stronger counterargument about the criticisms
              Kosuke explained that, yes, you might be able to tell that a device is a TV from the user agent string
                           but that there aren't standards for knowing that a device is a TV in that way
              Kosuke said that TVs may have looser security requirements than some other devices
              Vittorio suggested that we ask the W3C about adding information to the user agent string
                           saying that the device is a TV or has limited input capabilities
              Vittorio said that making something a standard requires that it has particular characteristics
                           That it be enforceable, that there be demand for it
                           He doesn't feel that it's a good candidate for standardization but he won't speak against it if it is adopted
              DW said that he doesn't see much use of the display parameter
                           He said that just knowing it's a TV doesn't tell the OP what behaviors it can count on
                           In most cases, he wouldn't know what actions to take based on the display parameter
              Nat wondered whether knowing more, such as 1024x768 display size, might be useful
              DW said that by the time the OP got a request, it could already tell, for instance, that the device wanted WEP content
                           He said that he wouldn't know what to do if he received display=tv
                           He'd like to know what user experiences should be triggered by the parameter
              Kosuke said that he can go back to the TV people and ask them what kinds of actions they want the parameter to trigger
                           Nat agreed that having that data would be useful
              Mike concluded that we will discuss possible adoption again once we have considered the additional data
              Later in the call, Aaron joined
                           He was curious if there are things that can't be learned from the invoking environment that are useful

Trust Chain CBOR Header Parameter
              Giuseppe plans to propose a Trust Chain COSE Header Parameter
              https://github.com/peppelinux/cose-sign-header-openid-federation-trust-chain/blob/master/draft-cose-sign--header-trust-chain.md
              Mike owes Giuseppe feedback on his draft

PRs
              https://bitbucket.org/openid/connect/pull-requests/
              PR #529: Added support for trust mark delegation.
                           Giuseppe gave the example of vehicle inspection, where the body mandating the inspection isn't the one doing it
                           There are currently two approvals
                           More reviews are requested
              PR #507: feat: [Federation] added iat and exp in trust marked endpoint
                           Unless a reason to keep working on this is stated before then,
                                         we'll plan to close this during the Federation editors' call on Friday

Open Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              #1752: Core - 15.5.3 CSRF Attack on Fragment Response Example
                           Adam Strickland responded with a new comment
                           Mike said that he still isn't clear to him what specifically to do to address Adam's concern
                           Mike will ask for specifics in an issue comment
              #1958: invalid_or_missing_proof and invalid_proof
                           Nat tagged the issue with the component Credential Issuance
              #1955: [Federation] Policy language: disambiguation about subset_of and essential operators
                           We will discuss possibly adding the requested table during Friday's Federation editors' call

Next Call
              The next call will be Thursday, June 29 at 7am Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230627/339ee49a/attachment-0001.html>


More information about the Openid-specs-ab mailing list