clarify protocol for retrieval of a status list

[mprorock]

probably based on url, but should be clarified in the spec text

[jandrieu]

SHOULD language is ok. MUST would be problematic.

[andresuribe87]

Somewhat related, w3c/vc-json-schema#207 added ohttp guidance. It was done non-normatively.

[iherman]

The issue was discussed in a meeting on 2023-09-15

• no resolutions were taken

View the transcript

1.6. clarify protocol for retrieval of a status list (issue vc-status-list-2021#44)

See github issue vc-status-list-2021#44.

Manu Sporny: clarify the protocol .... for --- list ...
… unless anyone objects ... it should be http-over-url.
… should be simple ... people can use different protocols ...

Kristina Yasuda: i have not heard anyone sending status lists over PE.

Manu Sporny: should be expressed ... should be able to be retrieved over http ... anyone disagrees?

Joe Andrieu: binding a resource to its transport type is flawed ... not sure it makes sense ...
… if i see a status list ... it can be FTP ...

Brent Zundel: i agree with you, and was happy when manu said SHOULD.

Andres Uribe: i'd like to see HTTPS.

Brent Zundel: of course.

Kristina Yasuda: do we also how the url is being fetched? post/get?

Manu Sporny: yeah, good questions ... this is where it gets complicated ... just say ... yon should use a HTTPS url, but that doesn't mean that you can't use FTP or ssh:// ...
… preferring to use oblivious http, rather than plain http ... that's where it gets more complicated .... recommending ... we'll just have to work on the details on the PR ...
… the more prescriptive we get the harder the PR is.
… right place to work on that is in the PR ... would that work?

Kristina Yasuda: assuming you are the one writing the pr ... are you going to specify whether it is going to be a GET or POST?

Manu Sporny: i think it is goin to be a GET.
… lets say, a GET, ideally over oblivious HTTP, no query parameters, no fragment identifiers ... any objections?

Sam Goto: ?

Kristina Yasuda: hard to say right now if that works ...
… sounds reasonable ... intuition feels like there is something out there already ...

Kristina Yasuda: i have questions on actually recommending OHTTP - it is still in draft in IETF. not comfortable with that.

[msporny]

PR #107 has been raised to address this issue. This issue will be closed once PR #107 has been merged.

[msporny]

PR #107 has been merged, closing.