# WG Meeting: 2022-07-25 ## Agenda - [Simple & Complex Subject Identifiers](https://github.com/openid/sharedsignals/issues/85) - [endpoint_url <-> url](https://github.com/openid/sharedsignals/issues/79) - [Include format in a config example](https://github.com/openid/sharedsignals/issues/54) ## Attendees - Shayne Miel (Cisco) - Eric Karlinsky (Okta) - Atul Tulshibagwale (SGNL) - Steve Venema (ForgeRock) - Apoorva Deshpande (Okta) ## Notes ### Simple and Complex Subject Identifiers - [Steve] Why are we inventing something new when the SecEvents SubIds draft is becoming an RFC already and has the "aliases" option - [Shayne] Aliases isn't formatted correctly to hold information such as "user", or "device", or other - [Steve] I was thinking of "device" or "user" as extensions of SubIds - [Steve] we would define additional formats in the SubIds, such as "device", "user", etc. - [Atul] The "identifiers" is an array, which would allow duplicates of "user" and "device" - [Shayne] Benefit of using "complex", is that you can have a "user" element, and it can have any format. Not so in the aliases way of doing things. - [Steve] Example came from framework spec. Main attraction is that subject types are well defined and registered. But you lose the semantics of "user" and "device" if you are just using aliases with simple subjects - [Shayne] Is it so bad to lose those semantics? The risk is clashes - i.e. a user and device being misidentified for each other. But how likely is that? - [Shayne] Feeling like maybe we don't need Complex Subjects at all - [Steve] Feeling like Complex Subjects are as good as we've got - [Both] Let's continue debate next week ### Endpoint URL <-> URL - [Atul] What is the sensitivity to breaking the implementer's draft? - [Eric] Reviewing the thread to understand impact. Need to defer to Apoorva ### Include Format in Config Example - [Shayne] I can create a new PR for this ## Action Items - Shayne to create PR to resolve [#54](https://github.com/openid/sharedsignals/issues/54)