[Openid-specs-risc] Issue #53 discussion

[Shayne Miel (smiel)]

Yes, that was my exact thinking for how we should handle this. A PR would be great!

Shayne
________________________________
From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Steve Venema via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Sent: Friday, June 16, 2023 4:32 PM
To: OpenID RISC List <openid-specs-risc at lists.openid.net>
Subject: [Openid-specs-risc] Issue #53 discussion

Atul, Shayne, et al.,

I've been thinking a bit more about Issue #53<https://github.com/openid/sharedsignals/issues/53> that we discussed on this week's call. Could we use the pattern described by "aliases" identifier format (see §3.2.8 of draft-ietf-secevent-subject-identifiers-17<https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers-17#name-aliases-identifier-format>) to cover this use case? It seems well aligned with what the spec is trying to capture here, but I'm pretty new to this stuff and might be totally off base. Or is this draft secevent spec moribund from an SSF perspective?

If you like the idea, I'd be happy to draft up a PR for review/discussion.

Regards,

-Steve
--
[ForgeRock]<https://www.forgerock.com/> Steve Venema
Distinguished Engineer  |  ForgeRock
t +1 (425) 825-0855  |  e steve.venema at forgerock.com<mailto:steve.venema at forgerock.com>
web www.forgerock.com<https://www.forgerock.com/>
________________________________
ForgeRock values your privacy<https://www.forgerock.com/your-privacy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230620/3cb761c9/attachment-0001.html>