[Openid-specs-risc] Question on delivery methods

[Phillip Hunt]

Tim,

I’m not sure what you mean by “I don't believe the secevent RFCs say how they should be referenced”.  They would never do that.

Inside the stream configuration which is entirely within the SSEF, I think you can reference any way you want. 

The confusion I had was that https://schemas.openid.net/secevent/risc/delivery-method/push <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschemas.openid.net%2Fsecevent%2Frisc%2Fdelivery-method%2Fpush&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cd06ecf65fc4e4cfd040a08da81470ecf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637964441246055504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=8dBaPzuXSlhURhwyC40MW%2F%2B5Le2iVNAbQ2UcryzkrW8%3D&reserved=0> suggested an entirely different method than RFC8935. If that’s not the intention, then just use RFC8935 or "https://www.rfc-editor.org/rfc/rfc8935.txt”.   The rfc-editor link would be considered the authoritative link for an RFC.

The openid specific URI had given me the impression openid was doing yet another delivery method than the IETF specs (which of course I could not find).

Phillip Hunt
@independentid
phil.hunt at independentid.com




> On Aug 18, 2022, at 11:56 AM, Tim Cappalli <Tim.Cappalli at microsoft.com> wrote:
> 
> Hey Phil – thanks for bringing this up. I don't believe the secevent RFCs say how they should be referenced.
>  
> Are you suggesting we should reference the RFC numbers instead of URIs?
>  
> Tim
>  
> From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Phillip Hunt via Openid-specs-risc <openid-specs-risc at lists.openid.net>
> Date: Thursday, August 18, 2022 at 14:28
> To: OpenID RISC List <openid-specs-risc at lists.openid.net>
> Subject: [Openid-specs-risc] Question on delivery methods
> 
> Looking at the shared signals framework spec (https://openid.net/specs/openid-sse-framework-1_0-ID1.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-sse-framework-1_0-ID1.html&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cd06ecf65fc4e4cfd040a08da81470ecf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637964441246055504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=vU9qrwiM04aC1lRqA43HAupl9ghRGA2ss5q%2B1oU%2Bvfs%3D&reserved=0>), 
>  
> I noticed the delivery methods are not RFC8935/8936 (as per the SECEVENTS specs) but instead are: 
> https://schemas.openid.net/secevent/risc/delivery-method/push <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschemas.openid.net%2Fsecevent%2Frisc%2Fdelivery-method%2Fpush&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cd06ecf65fc4e4cfd040a08da81470ecf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637964441246055504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=8dBaPzuXSlhURhwyC40MW%2F%2B5Le2iVNAbQ2UcryzkrW8%3D&reserved=0>
> https://schemas.openid.net/secevent/risc/delivery-method/poll <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschemas.openid.net%2Fsecevent%2Frisc%2Fdelivery-method%2Fpoll&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cd06ecf65fc4e4cfd040a08da81470ecf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637964441246055504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=fh%2Be0K4rK0ezQOxH%2FxV8FcWWAYr%2BHqkgEl6GmZf%2FTEA%3D&reserved=0>
> Is there a difference between these methods and RFC8935, RFC8936?  If they are different, is there a specification for these methods?  Near as I can tell, the CISCO shared signals implementation is the same.
>  
> Thanks,
>  
> Phillip Hunt
> @independentid
> phil.hunt at independentid.com <mailto:phil.hunt at independentid.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220818/63f13807/attachment.html>