<@U024CJMG22J> has joined the channel
<@U013SSREL0H> has joined the channel
<@U024KC347B4> has joined the channel
<@U035ZHBF21H> has joined the channel
<@U035JNUPF1V> has joined the channel
<@U03N48D5VD1> has joined the channel
<@U035WESCM0V> has joined the channel
New version of credential schema and samples pushed to for the new QVI Authorization Credentials. This update contains 2
new credential types, ECR Authorization vLEI Credential and OOR Authorization vLEI Credential
which will be included in the chain of the ECR and OOR credentials respectively. KERIpy was
updated as well.
<@U02MD0HA7EJ> has joined the channel
<@U03P53FCYB1> has joined the channel
<@U035R1TFEET> has joined the channel
<@U03QRSUA87Q> has joined the channel
Thank you <@U03U37DM125> and Ubisecure for creating RapidLEI, which made
getting the RootsID LEI straightforward
. When Provenant QVI is ready <@U035JNUPF1V>
<@U03RLLP2CR5> , RootsID would like to be one of your first vLEI customers
<@U03U37DM125> has joined the channel
<@U03RLLP2CR5> has joined the channel
Very cool guys!!
I agree that RapidLEI is great; that's where we got our LEI as well.
We should be ready to issue vLEIs by the end of this next week, <@U035R1TFEET>!
<@U04DQE2G36F> has joined the channel
<@U03RRS6FTNH> has joined the channel
<@U04HMQT1XFV> has joined the channel
<@U04GUPCB1M4> has joined the channel
<@U04H17ZEX9R> has joined the channel
can someone give me a brief explanation on what the vlei-server does? A
pointer to some doc will help also.
Number of replies: 2
It serves static vLEI schema (and credential) files on http port
7723. The url of the files is their SAID.
For example this file
is served at this url
The vLEI schemas are referenced in Keri oobi configurations, for example here
Thanks!!
It serves static vLEI schema (and credential) files on http port 7723. The
url of the files is their SAID.
For example this file is
served at this url
The vLEI schemas are referenced in Keri oobi configurations, for example here
Thanks!!
<@U04NF2VP5GA> has joined the channel
Has anyone encountered with the problem running the
`./scripts/create-local-aid.sh` script?
It seems my Local AID does not get the `receipts` from the `witness` . The error is as below
Waiting for witness receipts... ERR: unable to find a valid endpoint for witness BHeD7WvSDGwm0glBHGTuHpGeMRq7HyCOAJ8h_epQyHkRandWitnesses: Count: 5 Receipts: 0 Threshold: 5
Number of replies: 10
The error listed (ERR: unable to find a valid endpoint for witness) indicates that the database was initiated without pointing to a config file that contains OOBIs for that witness. You need to load the OOBI for that witness in a config file or directly with `kli oobi resolve` before trying to using the witness in an AID.
<@U024CJMG22J> thanks for the help, will try to do that
<@U024CJMG22J> So, should `BHeD7WvSDGwm0glBHGTuHpGeMRq7HyCOAJ8h_epQyHkR` be in the `qar-config.json` during the `init` event?
It should be one of the AIDs resolved from the GLEIF witness OOBIs, which are the top 5 URLs in `iurls` that have name parameters `gleif-0`, `gleif-1` , etc.
By the way, I just manually checked and the `gleif-3` is down
That is probably the culprit
I'll escalate the issue to GLEIF IT
thanks a lot
Ok, I tracked down the issue. The QVI repo uses GLEIF test witnesses in the template config files as examples. QVIs are responsible for standing up their own witness pool and should update these config files with their won witness information before creating AIDs.
Regardless, this particular witness (gleif-3) was rebooted and lost its IP address. I've updated the config file in the repo with the new address.
thank you so much <@U024CJMG22J>
The error listed (ERR: unable to find a valid endpoint for witness) indicates that the database was initiated without pointing to a config file that contains OOBIs for that witness. You need to load the OOBI for that witness in a config file or directly with `kli oobi resolve` before trying to using the witness in an AID.
<@U024CJMG22J> thanks for the help, will try to do that
<@U024CJMG22J> So, should `BHeD7WvSDGwm0glBHGTuHpGeMRq7HyCOAJ8h_epQyHkR` be in the `qar-config.json` during the `init` event?
It should be one of the AIDs resolved from the GLEIF witness OOBIs, which are the top 5 URLs in `iurls` that have name parameters `gleif-0`, `gleif-1` , etc.
By the way, I just manually checked and the `gleif-3` is down
That is probably the culprit
I'll escalate the issue to GLEIF IT
thanks a lot
Ok, I tracked down the issue. The QVI repo uses GLEIF test witnesses in the template config files as examples. QVIs are responsible for standing up their own witness pool and should update these config files with their won witness information before creating AIDs.
Regardless, this particular witness (gleif-3) was rebooted and lost its IP address. I've updated the config file in the repo with the new address.
thank you so much <@U024CJMG22J>
One of our customers wants to continue to learn about KERI/GLEIF. <@U03P53FCYB1> just did a nice intro to KERI and the Cardano Backer. I would like to present GLEIF to them next week. I’m happy to leverage material like this but if anyone has slides/youtube/podcast…. i would happily digest those…. and would loooove to go through concrete examples. We had discussed a KERI community governance framework to sign KERI documentation… but starting up that governance document would likely need to leverage past work. All links appreciated :raised_hands:
So contains all the documents we created for the vLEI EGF.
For a community EGF we might want to start by discussing what exactly the "ecosystem" is, for the vLEI we built it around the "vLEI", who could issue them, what their purpose was, and what the provenance chain should be for issued credentials (then Karla McKenna wrote a lot of documents).
For a community maybe we start by having a WoTMembershipCredential, it could include a rules section speaking to code of conduct or the licenses contributions are made under, you could then have the EGF say something like commits must contain a SAID with an attached signature (most compact CESR representation of an ACDC) of the `git diff`and using the keys associated with an AID and to which was issued a WoTMembershipCredential, then go even further and create a GitHub action that verifies the signature given a known WoT witness pool (the EGF might suggest people wishing to participate in the community run a witness) and rejects it if it's not valid - idk then you've just solved code supply chain validation or something.
I am obviously very interested in the discussion (in all our free time)
Data attestations of "known understanding" could be done in the same way, which was Henks original
suggestion that sparked the idea.
technically this probably doesn't belong in <#C03UQQTCA8P|vlei> happy to create a <#C04QX9F6R1A|governance> to explore this
<@U02PA6UQ6BV> has joined the channel
<@U02PA6UQ6BV> :eyes:
I got a little confused with the notation of the `threshold` set in the Multisig process.
The threshold of each participant in a party is in the form of a fraction `a/b` .
Does it mean
1. it requires `a` members out of `b` members to authorize the transaction
or
2. It requires each member with threshold of `a/b` + `c/d` and so on ... until the sum is `>= 1`
Yes, when using fractionally weighted thresholds, you have to have valid signatures from enough members so that the members fractions equal at least 1
Thanks <@U024CJMG22J>. Then if I have a party of 5 members which requires at least 2 members to sign a transaction, then I have to set the threshold to `3/5` not `2/5`.
No, you could just assign each member `1/2` . Or even easier, specifying `2` works too
Oh wait, I can set each to 1/2
Yeah, my bad. I was too attached to the `t-out-of-n` notion.
The fractionally weighted thresholds work when you have members in different signing "classes". So for example if you have 3 members that sign events on a regular basis, you could have each of them with `1/2` so you only ever need 2 of them for a valid event and then if you have 5 escrow members that are only used in an emergency you could assign them each `1/5` so you would need all five to sign or one of the first 3 and 3 of the escrow signers (if two of the first 3 become permanently unavailable or compromised).
I see, that's the beauty of using fractional weight threshold
I made a map for all vLEI credential schemas and would like to share it here.
Any feedback or correction is welcome!
Number of replies: 3
this is great! i hadn’t realized the nuance of the ECR credential (QVI or LEI issued) so I took a look at the governance framework doc and it confirms
I haven't confirmed the schema SAIDs but the layout looks good to me
Thank you!
this is great! i hadn’t realized the nuance of the ECR credential (QVI or LEI issued) so I took a look at the governance framework doc and it confirms
I haven't confirmed the schema SAIDs but the layout looks good to me
Thank you!
I have a quick question for either <@U024CJMG22J> or <@U024KC347B4>. The highlighted part says that the same aliases should be used for both internal and external AIDs. Is this intentional, or the manual is meant to say “QVI Internal AID” and “QVI External AID”.
It also seems to me that the manual is missing how a delegator (External GLEIF AID) is added using KERI Interactive Multisig Shell (KIMS).
I’ll review the documentation and reply in the morning
KIMS has a `delegator` command for adding a delegator. I’ll also make sure that is included.
Number of replies: 1
Thank you!
Thank you!
Not sure if this is the right place for this qns, but here goes:
Is vLEI (Keri)'s model trust-worthy enough to sign financial transaction events like a blockchain? Is vLEI considered an ultimate trust model like the blockchain, or just a high-trust one? I was thinking if it can be used as a financial transaction vehicle, since it opens up to a lot of possibilities as you don't need to pay with tokens for a financial transaction and therefore opens up to non-commissioned and highly convenient transaction usage.
I can't see any stake or incentive for the witnesses, watchers and etc. to ensure a ultimate trust model. Also, Im not sure if the witnesses can handle that much volume.
Can anyone enlighten me on this?
Or is KERI orderless data structure only suitable for identity?
Number of replies: 3
KERI is not orderless. It has a hash-chained data structure.
But it doesn’t have a consensus mechanism.
Key events don’t need total global ordering, therefore no blockchain with a consensus mechanism is strictly needed.
Afaik KERI uses a consensus mechanism to try and “recover” from duplicitous data: PBFT.
I think this question is for KERI in general and not specifically for vLEI, so I guess <#C013LDPHYGL|general> might be more appropriate. But here is my take.
KERI is specifically designed to be a key management infrastructure for identity systems. Once you have KERI as a foundational layer, you can build any application on top of that. You can certainly build a KERI-based financial application where signatures on transactions are verified using the KERI protocol.
However, it is important to note that KERI is not ‘double-spending proof’ so you cannot build something like Bitcoin using KERI by itself. Though one can definitely use KERI in combination with blockchains to build a double-spending-proof application.
In the second part of your question, I think it depends on what you mean by “ultimate trust”. Trust in identity systems always consist of “human trust” and “technical trust”. See trust over IP .
To me, and to many others in this community, KERI is by far the best technology for technical trust. For human trust, you need a governance framework on top of technical trust, and this is where GLEIF plays its role.
"I can't see any stake or incentive for the witnesses, watchers and etc. to ensure a ultimate trust model. Also, Im not sure if the witnesses can handle that much volume."Again, KERI is not double-spending proof, so it doesn’t provide a tokenomic incentive for participating parties, unlike miners in proof-of-work blockchains and validators in proof-of-stake blockchains. Witnesses are designated by “controllers” to provide a “key promulgation service”, basically a service for others to discover their keys. Watchers are designated by “validators” to provide a “key confirmation service”, basically a service to monitor the witnesses. Witnesses and watchers get key events and simply sign on them. They are not required to do a computationally heavy algorithm like proof-of-work. So I don’t see why they cannot handle the volume. A controller can also horizontally scale by assigning more witnesses.
KERI is not orderless. It has a hash-chained data structure.
But it doesn’t have a consensus mechanism.
Thank you so much <@U04H17ZEX9R>. I will go through more of the docs and understand more about the "not double-spend proof" and also how trust is established with witnesses and watchers. Is it BFT or just high-trust based?
Number of replies: 2
It is BFT.
Thank you
It is BFT.
Thank you
Really appreciate you taking your time to answer my questions Nuttawut
Key events don’t need total global ordering, therefore no blockchain with a consensus mechanism is strictly needed.
Afaik KERI uses a consensus mechanism to try and “recover” from duplicitous data: PBFT.
I am running the agent to audit the ACDC issued using the vLEI schemas. I demo issuing the QVI credential and the Legal Entity (LE) (which has its edge to the QVI credential.
When I revoked the QVI credential and present the latter LE credential to Sally, the Sally still sees its status as `issued` not `revoked` . Shouldn’t the LE credential be revoked as its parent ACDC (QVI Cred) had been revoked ?
P.S. When I use `kli vc list` to check the LE credential, its status is still “issued” as well, not revoked.
Number of replies: 1
I have made a for this issue
I have made a for this issue
I just listened to the record of the last keri-dev and have a question on the delegation of QVI AID, following the question asked by <@U035ZHBF21H>.
In [Technical Requirements Part 1: KERI Infrastructure] of the vLEI ecosystem governance framework Section 6.6
The Delegated AID of a Qualified vLEI Issuer MUST set the Do Not Delegate configuration trait to True. (NOTE: This may change in future versions in order to accommodate horizontal scalability of the vLEI signing infrastructure.)I am wondering if the following approach is allowed within the ecosystem. 1. A QVI incepts a new AID (AID1) that is different from the one used as the QVI AID (AID0) 2. Use AID0 to issue a Legal Entity vLEI to AID1—i.e., the QVI issues Legal Entity vLEI to itself using AID1 3. Use AID1 to delegate to another new AID (AID2) 4. Use AID2 to issue credentials. Note: The issued credentials in Step 4 are not related to the vLEI credentials.
Number of replies: 2
As far as a QVI issuing their own LE credential to themselves... we have allowances for the first (or maybe first few, I'm not sure) QVI(s) to issue their own LE credential, but it will not be supported once we have a sufficient number of QVIs available.
Either way, once a QVI (or any organization) has their LE vLEI credential, they are clear to issue any number of non-vLEI credentials to themselves, chained to their LE credential. That is the primary way the vLEI can be used to bootstrap other ecosystems.
Thanks for the confirmation!
As far as a QVI issuing their own LE credential to themselves... we have allowances for the first (or maybe first few, I'm not sure) QVI(s) to issue their own LE credential, but it will not be supported once we have a sufficient number of QVIs available.
Either way, once a QVI (or any organization) has their LE vLEI credential, they are clear to issue any number of non-vLEI credentials to themselves, chained to their LE credential. That is the primary way the vLEI can be used to bootstrap other ecosystems.
Thanks for the confirmation!
For becoming a QVI is there any starting point or guiding framework issued as to the technical tools (repos in GLEIF-IT and WebOfTrust?) and how to use those tools to meet the QVI issuing requirements already listed on their site or is this supposed to be customized by each QVI issuer using whatever tools from those places + stuff they develop themselves internally (or shared externally as it may be)?
The second option.
Number of replies: 1
Provenant is working to improve the vLEI issuance process for QVIs and their customers. Happy to discuss
GLEIF runs a qualification program to guide potential QVIs through the process.
roger
Provenant is working to improve the vLEI issuance process for QVIs and their customers. Happy to discuss
The keri dids are included in the governance documents but they don't resolve via the universal resolver. Can kli resolve these dids?
Number of replies: 5
I don’t know all of the historical support for KERI DIDs. But am aware of some demonstrations and discussion about support for KERI AIDs as DIDs. This project was a PoC for did keri resolution and is inspiring new work (that me/GLEIF are actively working) for the ToIP did:webs spec, which uses KERI. We will have a reference implementation for a resolver and server. And the goal is to have the resolver available to the DIF universal resolver by mid-October (Fall IIW 2023 conference)
<@U035R1TFEET> cool.
Also we’ll add support in keripy for generating did docs from KELs, etc.
That ToIP task force is in the early weeks, and you are welcome to attend/contribute, the slack channel is and we meet on Fridays
cool, will do. Glad to help where I can as well.
I don’t know all of the historical support for KERI DIDs. But am aware of some demonstrations and discussion about support for KERI AIDs as DIDs. This project was a PoC for did keri resolution and is inspiring new work (that me/GLEIF are actively working) for the ToIP did:webs spec, which uses KERI. We will have a reference implementation for a resolver and server. And the goal is to have the resolver available to the DIF universal resolver by mid-October (Fall IIW 2023 conference)
<@U035R1TFEET> cool.
Also we’ll add support in keripy for generating did docs from KELs, etc.
That ToIP task force is in the early weeks, and you are welcome to attend/contribute, the slack channel is and we meet on Fridays
cool, will do. Glad to help where I can as well.