22:57:42 <RRSAgent> RRSAgent has joined #vcwg-special
22:57:46 <RRSAgent> logging to https://www.w3.org/2023/01/31-vcwg-special-irc
22:57:46 <mprorock> mprorock has joined #vcwg-special
22:58:49 <brentz> brentz has changed the topic to: Meeting Agenda 2023-01-24: https://github.com/w3c/vc-status-list-2021
22:59:00 <brentz> brentz has changed the topic to: Meeting Agenda 2023-01-31: https://github.com/w3c/vc-status-list-2021
22:59:09 <brentz> zakim, start the meeting
22:59:09 <Zakim> RRSAgent, make logs Public
22:59:11 <Zakim> please title this meeting ("meeting: ..."), brentz
22:59:19 <brentz> meeting: VCWG Special Topic Call
22:59:26 <brentz> chair: Brent Zundel
23:01:46 <mprorock> present+
23:01:56 <Orie> Orie has joined #vcwg-special
23:02:00 <shigeya> present+
23:02:04 <Orie> scribe+
23:02:07 <Orie> present+
23:02:24 <manu> present+
23:02:27 <Orie> Topic: VC Status List
23:02:41 <manu> q+ to mention some PRs.
23:02:54 <brentz> ack manu
23:02:54 <Zakim> manu, you wanted to mention some PRs.
23:02:56 <Phil_ASU> Phil_ASU has joined #vcwg-special
23:03:01 <manu> subtopic: https://github.com/w3c/vc-status-list-2021/pull/45
23:03:04 <decentralgabe> decentralgabe has joined #vcwg-special
23:03:06 <Phil_ASU> present+
23:03:08 <decentralgabe> present+
23:03:12 <andres> andres has joined #vcwg-special
23:03:19 <Orie> manu: there 2 PRs follow up from discussions last week
23:03:28 <Orie> ... they cover bitstring and dereferencing.
23:03:56 <Orie> ... it adds an image to talk about encoding, and some language.
23:04:12 <manu> subtopic: https://github.com/w3c/vc-status-list-2021/pull/46
23:04:20 <Orie> ... next item, is regarding dereferencing
23:04:23 <Kerri_Lemoie> Kerri_Lemoie has joined #vcwg-special
23:04:29 <Kerri_Lemoie> present+
23:04:48 <Orie> ... issue #39 is about errors when you can't dereference.
23:05:02 <smccown> smccown has joined #vcwg-special
23:05:15 <Orie> ... we don't use these values, so it should not matter if they fail to dereference.
23:05:20 <kristina> kristina has joined #vcwg-special
23:05:24 <kristina> present+
23:05:29 <Orie> ... but it should fail during validation...
23:05:42 <Orie> ... new PR says throw an error during validation
23:05:57 <Orie> ... if the ids can be dereferenced
23:06:08 <Orie> ... can not*
23:06:12 <smccown> present+
23:06:20 <manu> s/can be/cannot be/
23:06:22 <brentz> present+
23:06:26 <kristina> i will def need some time to review the PRs
23:06:30 <TallTed> present+
23:06:32 <brentz> https://github.com/w3c/vc-status-list-2021/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
23:06:33 <Orie> Topic: Issue Processing
23:06:48 <brentz> subtopic: https://github.com/w3c/vc-status-list-2021/issues/4
23:07:00 <selfissued> selfissued has joined #vcwg-special
23:07:05 <selfissued> present+
23:07:10 <Orie> brent: sounds like the poster is seeking information
23:07:35 <Orie> Q=
23:07:36 <kristina> q+
23:07:37 <Orie> q+
23:07:44 <manu> scribe+
23:07:46 <brentz> ack kristina
23:07:59 <Orie> kristina: seems like a question that could impact spec design
23:08:12 <Orie> ... there was an option for the bitmap to be in a did doc before
23:08:23 <manu> q+ to note you can put bitmap elsewhere as long as there is a VC wrapping it?
23:08:34 <Orie> ... can it be made legal to put the bitmap list in a did doc?
23:08:41 <Orie> ... we could discuss
23:08:42 <Orie> q-
23:08:51 <brentz> ack manu
23:08:51 <Zakim> manu, you wanted to note you can put bitmap elsewhere as long as there is a VC wrapping it?
23:09:29 <Orie> manu: technically, you can use a status list URL, including a DID...
23:09:50 <Orie> ... dereferencing must be a VC currently, so a DID Document would not be secured.
23:09:56 <dwaite> dwaite has joined #vcwg-special
23:10:03 <dwaite> present+
23:10:07 <Orie> ... we don't currently have a way to support hosting the list in a did document
23:10:10 <kristina> q+
23:10:20 <Orie> ... I am concerned about expanding the scope of a status list
23:10:36 <Orie> ... I know its possible to create URLs that would work for this.
23:10:45 <brentz> ack kristina
23:11:16 <Orie> kristina: I don't have strong opinions either way, does an object that is stored under a URL or a DID... does it have to be signed?
23:11:32 <Orie> ... if you trust the PKI, does it still need to be signed?
23:11:42 <Orie> ... maybe the answer is you sign anyway...
23:12:04 <Orie> ... from interop perspective, less options the better
23:12:15 <Orie> ... can the result be a simple JWS?
23:12:31 <manu> q+ to note if you don't sign, the security concerns get a bit more dicey, we lose a use case (possibly).
23:12:38 <Phil_ASU> q+
23:12:48 <Orie> ... seems like maybe folks should not need to understand the VC spec to process the status list
23:12:53 <Orie> q+
23:12:57 <brentz> ack manu
23:12:57 <Zakim> manu, you wanted to note if you don't sign, the security concerns get a bit more dicey, we lose a use case (possibly).
23:13:06 <shawnb> shawnb has joined #vcwg-special
23:13:10 <shawnb> present+
23:13:23 <Orie> manu: if we don't sign it, they you do need to trust the domain / did method / web host / did controller ... etc...
23:13:38 <Orie> ... we could say, it does not need to be signed, just make sure its secured.
23:13:55 <Orie> ... then it opens the attack surface on the integrity of the list
23:14:30 <Orie> ... why a vc? the reason they go to the list, is because they are coming from a VC... we know they can already process VCs.
23:14:45 <Orie> ... its not a surprise for he implementer to get another VC.
23:15:04 <Orie> ... could the list be signed differently, but then we have mixed technologies for the list and the original vc
23:15:17 <Orie> ... for those reasons we built it on top of VCs
23:15:33 <brentz> ack Phil_ASU
23:15:50 <manu> q+ to note lost use cases -- if it's not signed, holder can't deliver it.
23:16:00 <Orie> phil_ASU: also concerned about the attack surface, but also concerned about multiple ways to achieve the same objective.
23:16:02 <kristina> q+
23:16:25 <kristina> "The statusListCredential property MUST be a URL to a verifiable credential." should be changed to "URI"
23:16:38 <Orie> ... if they can already handle a VC, we should ask them for clarity regarding why they are asking the question regarding ethereum
23:16:42 <kristina> if DIDs, ethereum URLs are to be allowed
23:16:44 <brentz> ack Orie
23:17:27 <manu> Orie: Manu covered a lot of what I would say. I think it's a mistake for a credential status type to have a lot of agility on the security format. It seems ok to me to have the URL structure be one of any possible valid URLs that dereference to a VC. The DID side of it I don't have strong objections to.
23:18:40 <manu> Orie: However, switching to a different cryptographic suite from what the VC uses, it could make the end verifier implement multiple cryptosuite to implement a revocable credential, don't think that's a good thing.  If the objective is to store the list on a blockchain, on a website or without security... each of those are separate items and it's possible that they could all be well supported if they all have a unique type and they're supported
23:18:40 <manu> separately.
23:18:55 <manu> Orie: I think it's a mistake to expand the scope of status list to do all of those things.
23:19:01 <manu> ack manu
23:19:01 <Zakim> manu, you wanted to note lost use cases -- if it's not signed, holder can't deliver it.
23:19:15 <Orie> manu: one use case to mention, on why do we sign...
23:19:24 <Orie> ... signing enables offline presentation by the holder
23:19:53 <Orie> ... this allows for revocably credentials to be presented without going to the network
23:20:20 <Orie> ... this can also enable the verifier to not need to make network requests
23:20:31 <brentz> ack kristina
23:20:34 <Orie> ... the holder may present the list directly to the verifier
23:20:41 <Phil_ASU> +1 for preserving the holder providing the status list directly to the verifier.
23:20:46 <Orie> kristina: thanks for the comments
23:21:17 <Orie> ... it would be good to clarify the answers to these questons
23:21:18 <manu> agree that we should clarify all of these things in the spec... I don't think we say many of these things.
23:21:21 <manu> q+ on "URI"
23:21:26 <Orie> ... should it be URI instead of URL ?
23:21:31 <brentz> ack manu
23:21:31 <Zakim> manu, you wanted to comment on "URI"
23:21:40 <mprorock> url is new syntax via whatwg
23:21:47 <Orie> manu: normally we would have put URI, but there was a big fight over URI vs URL and WHATWG
23:21:55 <Orie> ... so we should call everything a URL
23:22:06 <Orie> ... so now we call everything a URL
23:22:08 <mprorock> manu schooled the sh*** out of me on this and i still have bad habits on uri etc
23:22:23 <kristina> that's the answer i expected
23:22:26 <brentz> q?
23:22:27 <Orie> ... we can't call them URIs or we will get yelled at by WHATWG
23:22:29 <andres> That just underscores why url should be used everywhere :P
23:22:47 <Orie> brent: any next steps that need to go into the issue?
23:22:52 <kristina> can open an issue on sending VC only
23:23:03 <Orie> manu: kristina asked for us to clarify in the spec on this, and we should.
23:23:21 <Orie> ... we should add a PR to comment on what we have just discussed
23:23:29 <mprorock> +1 manu - spec is good if you "know" not as good if you don't
23:23:41 <brentz> subtopic: https://github.com/w3c/vc-status-list-2021/issues/6
23:23:51 <Orie> q+
23:23:58 <kristina> (and I think the answer to issue #4 is they would have to host a VC under an ethereum URL)
23:24:05 <brentz> ack Orie
23:24:06 <manu> q+
23:24:15 <manu> Orie: I think this is trying to get at bad issuers.
23:24:56 <manu> Orie: They can track with status list if they do a 1:1 mapping -- what can the spec do to prevent issuers from being bad? The spec could mandate that you have a fixed size of the bitstring and spec can direct you to consume indexes randomly and not have new list... but malicious issuer can do whatever they wish.
23:25:18 <mprorock> +1 orie - people are bad on the internet sometimes, not sure we can solve it all
23:25:27 <manu> Orie: If you have to trust them for digital signature, they can do many other bad things, I think that's what he's asking about, don't know how much guidance we can place in here. Perhaps we should add something to Security Considerations wrt. things "not to do with the spec".
23:25:41 <manu> brentz: We can say an evil issuer is non-conformant.
23:25:44 <brentz> ack manu
23:25:52 <Orie> manu: yes, agree with orie and brent.
23:26:13 <Orie> ... we can't prevent bad issuers from being evil, we should write about this in security considerations section
23:26:28 <Orie> ... we have been trying to figure out if its detectable
23:26:45 <Orie> ... maybe wallets can detect that the issuer has lots of status lists?
23:26:58 <Orie> ... but it seems like a wallet can't know if this is happening
23:27:04 <mprorock> q+
23:27:11 <Orie> ... because of the design, its very hard to know if the issuer is evil
23:27:38 <Orie> ... issuers will be evil, and they will try to do things like this... and its hard for us to detect it... so we should comment on it in sec considerations
23:27:46 <brentz> ack mprorock
23:28:16 <Orie> mprorock: evil issuer is gonna support better 3rd party snooping an coordination?
23:28:28 <Orie> ... there are much easier ways around this for bad actors...
23:28:44 <andres> q+
23:28:44 <manu> truth, mprorock
23:28:53 <kristina> filed: https://github.com/w3c/vc-status-list-2021/issues/48
23:28:53 <brentz> ack andres
23:29:11 <Orie> andres: can enforcing the structure of the URL help?
23:29:17 <mprorock> q+
23:29:24 <Orie> ... perhaps URL structure could help?
23:29:26 <brentz> ack mprorock
23:29:50 <Orie> mprorock: see data brokers, and services... they are not going to make it obvious
23:30:10 <Orie> ... we should provide guidance for honest parties
23:30:25 <Orie> ... the bad guys will turn around and sell it, without leaving a trace in the open
23:30:53 <brentz> subtopic: https://github.com/w3c/vc-status-list-2021/issues/7
23:31:16 <Orie> brent: is status list 2021 expected to be issued by the same issuer as the credential
23:31:17 <Orie> q+
23:31:24 <brentz> ack Orie
23:31:53 <mprorock> 3rd party stuff could get interesting
23:32:24 <brentz> q+ to say as long as the issuer indicates where to retrieve the statuslist credential, does this matter?
23:32:32 <manu> Orie: as far as I know, the answer is "yes", but there are "hierarchy" concerns -- is the global company the same as the sub-company? Does it have to be with the same keys? I don't know the specific guidance on this, but errors would be thrown if the issuer is not matching. Looking for clear guidance on issuer, keys, etc. being the same vs. different.
23:32:34 <brentz> ack brentz
23:32:34 <Zakim> brentz, you wanted to say as long as the issuer indicates where to retrieve the statuslist credential, does this matter?
23:32:36 <kristina> also filed: https://github.com/w3c/vc-status-list-2021/issues/49
23:32:52 <manu> q+
23:33:18 <Orie> brent: the setup is that the issuer has issued a vc and the issuer has indicated where a verifier can retrieve the credential.... does it matter?... can an issuer delegate revocation authority?
23:33:18 <mprorock> question is "expected to be" not, what are all the crazy things we can do
23:33:19 <dmitriz> dmitriz has joined #vcwg-special
23:33:22 <brentz> ack manu
23:33:27 <dmitriz> present+
23:33:34 <Orie> manu: +1 to yes... the answer is yes in general
23:33:34 <kristina> One sentence that it might or might not match might be helpful
23:33:45 <kristina> we had the same question in openid4vci spec: "Depending on the Credential format, the issuer identifier in the issued Credential is not always a URL using the `https` scheme. Some other forms that it can take are a DID included in the `issuer` property in a [@VC_DATA] format, or the `Subject` value of the document signer certificate included in the `x5chain` element in a [@ISO.18013-5] format."
23:33:56 <Phil_ASU> q+
23:33:57 <Orie> ... its true, there are questions about hierarchy and global company vs local companies....
23:34:07 <kristina> q+
23:34:11 <Orie> ... and it may be bad for us to be overly strict in this regard
23:34:44 <Orie> ... I think what brent said is most telling, the issuer intended to point to where they sent you... you should probably trust the original issuer first.
23:34:56 <Orie> ... the original issuer, should be able to delegate
23:35:16 <Orie> ... it would be straight forward for us to say the issuer should be the same for both
23:35:36 <Orie> ... its probably better to just require both to be verifed, and leave the choice to the issuer
23:35:37 <brentz> ack Phil_ASU
23:36:05 <Orie> Phil_ASU: in the k12 space, highschools vs districts use case seems relevant...
23:36:36 <Orie> ... we have seen issues where there can be governance issues here
23:36:40 <brentz> ack kristina
23:36:46 <mprorock> +1 Phil we are lookng more at business rules and not closing those things off
23:36:59 <Orie> kristina: can we say the issuer may or may not match
23:37:07 <Orie> ... we did something similar in another spec
23:37:08 <manu> +1 kristina
23:37:13 <mprorock> +1
23:37:15 <Orie> +1 kristina
23:37:53 <brentz> subtopic: https://github.com/w3c/vc-status-list-2021/issues/9
23:38:04 <manu> q+
23:38:11 <Orie> brent: if the index is out of bounds... what should happen
23:38:14 <brentz> ack manu
23:38:20 <Orie> manu: it should raise an error
23:38:33 <Orie> ... if they are out of bounds, it should raise an error.
23:38:35 <kristina> q+
23:38:37 <mprorock> ill volunteer for a PR on this
23:38:42 <brentz> ack kristina
23:38:56 <manu> q+
23:39:01 <Orie> kristina: I don't disagree... throwing an error is fine, but perhaps we should define an error code?
23:39:06 <Orie> ... are there error codes?
23:39:12 <brentz> ack manu
23:39:32 <Orie> manu: checking the status index is part of the verification stage
23:39:40 <Orie> ... that would cause verify to fail
23:39:44 <mprorock> q+
23:39:50 <Orie> ... it gets into protocol
23:39:57 <kristina> error message?
23:40:03 <Orie> ... all we can say is you should throw an error
23:40:11 <Orie> ... we don't have error codes yet
23:40:32 <Orie> ... there is no way to surface these to the caller, unless we talk about protocol like vc api
23:40:52 <brentz> ack mprorock
23:40:53 <Orie> ... i don't think this spec, which is just data model and serialization, can say much about how errors are exposed
23:41:08 <Orie> mprorock: i'm not opposed to including informative guidance
23:41:18 <Orie> ... like 406 / not acceptable
23:41:31 <Orie> ... normative path, we should say MUST throw an error
23:41:42 <Phil_ASU> +1 to it should throw an error
23:41:45 <Orie> ... should users see it? we can't say anything about that
23:41:52 <manu> q+
23:41:58 <manu> q-
23:42:13 <kristina> q+
23:42:23 <mprorock> +1 manu
23:42:45 <Orie> manu: is there confusion over getting the list, like 404... vs during verification 406 might not make sense... maybe better 200 verified false
23:42:55 <Orie> ... seems like a protocol trap
23:42:57 <mprorock> agreed
23:43:09 <brentz> ack kristina
23:43:32 <Orie> kristina: good point on retrieval vs verify in the bitmap
23:43:48 <Orie> ... we should say 404 if its obvious is should be 404
23:43:54 <manu> +1 kristina, not finding the status list should be a 404 and should be in the spec.
23:44:12 <manu> q+ to note errors
23:44:13 <Orie> ... if we want to avoid protocol, error message is probably also a trap
23:44:17 <brentz> ack manu
23:44:17 <Zakim> manu, you wanted to note errors
23:44:30 <Orie> manu: we can define an algorithmic error message
23:44:44 <Orie> ... error_index_out_of_bounds and hand wave about it
23:45:06 <Orie> ... langauges / implementers can define how they want to handle it
23:45:11 <mprorock> +1 manu, e.g. you MUST return an error that indicates that the index is out of range through ERR_ABOVE_MAX
23:45:23 <brentz> subtopic: https://github.com/w3c/vc-status-list-2021/issues/11
23:45:43 <manu> q+
23:45:44 <Orie> brent: what should the type value be
23:45:48 <brentz> ack manu
23:45:59 <Orie> ... I think this is stale / old and has been fixed.
23:46:30 <Orie> manu:  this is about old langauge that no longer exists
23:46:32 <kristina> q+
23:46:55 <Orie> ... seems we should close this issue, and note that we have changed the name
23:47:03 <brentz> ack kristina
23:47:18 <manu> q+
23:47:23 <Orie> kristina: +1 to the direction, curious.... why is there a 2021 in the name, can we drop it?
23:47:25 <brentz> ack manu
23:47:36 <selfissued> Please delete the 2021
23:47:57 <Orie> manu: yeah, typically we version things... and we like to be able to tell versions apart
23:48:03 <shawnb> Can we use SemVer then?
23:48:06 <kristina> q+
23:48:12 <Orie> ... dates have been used fro crypto suites, so you can tell how old something is
23:48:22 <mprorock> +1 shawn
23:48:27 <Orie> ... we you see v1, v2, v3... you have no sense of time
23:48:35 <Orie> whereas dates tell you something about time
23:48:39 <mprorock> but is json, why just not add semver as a property in the json
23:49:01 <Orie> ... first question, do we want versioning? yes... do we want semantic versioning or date based versioning
23:49:16 <Orie> ... we do stuff differently all over the place
23:49:29 <Orie> ... dates are in names when time is important
23:49:35 <Orie> q+
23:49:43 <Orie> ... I will note that this has paid off well
23:50:01 <brentz> ack kristina
23:50:01 <Orie> ... because if we had not versioned we would have been stuck with RSA suites forever
23:50:19 <Orie> kristina: first question is what are we trying to version>
23:50:23 <manu> q+ to note we're trying to version the object and the spec.
23:50:35 <mprorock> https://github.com/w3c/vc-status-list-2021/issues/11#issuecomment-1411229291
23:50:36 <Orie> ... we should version specs based on publication date maybe
23:50:51 <Orie> ... lets agree on what we are trying to version, and then discuss how to do it
23:51:01 <manu> q+ to note that we version because data formats / fields might change in the future.
23:51:03 <Orie> ... I would be in favor of dropping date versioning
23:51:03 <brentz> ack Orie
23:52:32 <mprorock> dates typically imply bias (newer is better)
23:52:39 <kristina> I think cryptosuites versioning is different
23:52:43 <mprorock> or as it ages...
23:52:45 <manu> Orie: I also was surprised to learn about this long history of adding dates to specs to version them and recently in Chairing capacity came across IDNA2003 and IDNA2008 and UTS46 and it has rekindled my deep appreciation that people ahve always struggled on clean versioning schemes. It does seem to me that putting a date on things was more popular in the past then it is today, W3C community is last holdout to put dates on things and others have
23:52:45 <manu> moved on from this practice since then. Maybe an older convention and not current best practice. There are things out there that people are referring to and arguing over and fact that it has 2008 causes people toa rgue over it more than if it didn't.
23:52:50 <brentz> ack manu
23:52:50 <Zakim> manu, you wanted to note we're trying to version the object and the spec. and to note that we version because data formats / fields might change in the future.
23:53:04 <Orie> manu: I would not say its an old thing
23:53:09 <brentz> q+ to ask about closing this issue
23:53:13 <dmitriz> q+
23:53:19 <Orie> ... it was easy for us to just use dates, thats why we picked them
23:53:27 <Orie> ... people don't try to find new versions
23:53:51 <Orie> ... kristina asked, what are we trying to version... we are trying to version the "object"
23:53:54 <Orie> ... not the spec
23:54:20 <Orie> ... if we had started off without adding a version to the RDF type, we would have been trapped
23:54:50 <Orie> ... now we can add new RDF classes for each new type we create, so we can tell the RDF types apart
23:55:12 <Orie> ... people have strong opinion on this, feels like a rat hole
23:55:20 <kristina> q+
23:55:26 <brentz> Is StatusList2021 worse than StatusListV1 ?
23:55:43 <brentz> ack brentz
23:55:43 <Zakim> brentz, you wanted to ask about closing this issue
23:55:50 <kristina> filed an issue: https://github.com/w3c/vc-status-list-2021/issues/50
23:55:57 <dmitriz> @brentz: that was my question too
23:55:58 <Orie> brent: regarding this particular issue, feels like we can close it
23:56:01 <dmitriz> q-
23:56:05 <shawnb> +1 close it
23:56:10 <Orie> ... any objection?
23:56:22 <brentz> ack dmitriz
23:56:28 <kristina> q-
23:56:36 <Orie> dimitry: I was going to ask what you asked in chat
23:56:51 <kristina> +1 to StatusListV1
23:56:52 <Orie> is StatusListV1 better or worse than StatusList2023
23:57:02 <Orie> brent: closing this issue
23:57:22 <dmitriz> thaaanks Orie!
23:57:24 <shawnb> thanks, Orie :high-five:
23:57:35 <Phil_ASU> + putting a year in the status list ends of causing questions when there haven't been changes as people think i's moribund, not simply still doing strong. ;-)
23:57:53 <brentz> zakim, who is here?
23:57:53 <Zakim> Present: mprorock, shigeya, Orie, manu, Phil_ASU, decentralgabe, Kerri_Lemoie, kristina, smccown, brentz, TallTed, selfissued, dwaite, shawnb, dmitriz
23:57:56 <Zakim> On IRC I see dmitriz, shawnb, dwaite, selfissued, kristina, smccown, Kerri_Lemoie, andres, Phil_ASU, Orie, mprorock, RRSAgent, Zakim, brentz, TallTed, shigeya, dlehn, manu,
23:57:56 <Zakim> ... dlongley, stenr, csarven
23:58:14 <brentz> zakim, end the meeting
23:58:14 <Zakim> As of this point the attendees have been mprorock, shigeya, Orie, manu, Phil_ASU, decentralgabe, Kerri_Lemoie, kristina, smccown, brentz, TallTed, selfissued, dwaite, shawnb,
23:58:17 <Zakim> ... dmitriz
23:58:17 <Zakim> RRSAgent, please draft minutes
23:58:19 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/31-vcwg-special-minutes.html Zakim
23:58:27 <Zakim> I am happy to have been of service, brentz; please remember to excuse RRSAgent.  Goodbye
23:58:27 <Zakim> Zakim has left #vcwg-special
23:58:29 <brentz> rrsagent, bye
23:58:29 <RRSAgent> I see no action items