document_text
8 rows where source_id = "weboftrust-keri-main"
This data as json, CSV (advanced)
| id ▼ | source_id | kind | license | title | url | credit | chars | text |
|---|---|---|---|---|---|---|---|---|
| weboftrust-keri-main/2 | weboftrust-keri-main | repository prose file | Apache-2.0 | CONTRIBUTING.md | https://github.com/WebOfTrust/keri/blob/main/CONTRIBUTING.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/CONTRIBUTING.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 1177 | ContributingThis repository relates to activities in the Internet Engineering Task Force (IETF). All material in this repository is considered Contributions to the IETF Standards Process, as defined in the intellectual property policies of IETF currently designated as BCP 78, BCP 79 and the IETF Trust Legal Provisions (TLP) Relating to IETF Documents. Any edit, commit, pull request, issue, comment or other change made to this repository constitutes Contributions to the IETF Standards Process (https://www.ietf.org/). You agree to comply with all applicable IETF policies and procedures, including, BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being subject to a Simplified BSD License) in Contributions. In addition to the terms of the the IETF Standards Process described above all contributions to this repository fall under the specifics of the License in LICENSE.md this includes Apache2 licensing of patents. |
| weboftrust-keri-main/3 | weboftrust-keri-main | repository prose file | Apache-2.0 | LICENSE.md | https://github.com/WebOfTrust/keri/blob/main/LICENSE.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/LICENSE.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 1817 | LicenseAll software and documentation in this repository are Copyright 2021 KERI Contributors and all contributions to this repository are Licensed under the Apache License, Version 2.0 (the "License") here; As as defined in the License, contributions include but are not limited to patents, source code, specification text, documentation, comments and issues. You may not use the software or documentation in this repository except in compliance with the License. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS. You may obtain a copy of the License at Apache2. To remove any doubt as the origin on any contributions, all contributers are also bound by the Developer Ceritificate of Origin v1.1 (DCO 1.1) which may be found here As a GitHub repository, all contributions to this repository are also bound by the GitHub inbound=outbound policy. This may be found under Section D.6 here The legal structure of this repository with respect to the licensing of its associated contributions also follows GitHub's Open Source Guide reccomendations for open source standards and code. These may be found here In addition to the copyright and licensing restrictions described above, all contributions to this repository are contributions to the IETF standards process and are licensed accordingly. The IETF license terms are defined in the guidelines for contributions. |
| weboftrust-keri-main/4 | weboftrust-keri-main | repository prose file | Apache-2.0 | agenda.md | https://github.com/WebOfTrust/keri/blob/main/agenda.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/agenda.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 44799 | <hr>
tags: KERI, IETF, CommunityKERI Community Meeting AgendaChair: Samuel M. Smith email Co-Chair: Philip Feairheller email Meeting Bi-weekly starting on 2021-10-19 at 10 am EDT Agenda: https://hackmd.io/-soUScAqQEaSw5MJ71899w (linked from github but edited in HackMD) Zoom Meeting: https://us02web.zoom.us/j/89842900185?pwd=OEpXSU5pa29FR1A3OXFkUithZFNwQT09 Meeting ID: 898 4290 0185 Passcode: 300255 Calendar Invite: https://us02web.zoom.us/meeting/tZ0lc-uhrjsrEtFmV2aSfAzR015DDL-ld-hg/ics?icsToken=98tyKuGhpj8oE9SVsRGCRpx5Go-ga_PziGJcj7d7kSm3AhNVQxnEZrMXFpZTXdTU KERI Slack: keriworld.slack.com https://join.slack.com/t/keriworld/shared_invite/zt-14326yxue-p7P~GEmAZ65luGSZvbgFAQ Explanation of KERI development tools and techniques: KERI development environment MeetingsFuture Topics
ToDo
Weekly Agendas2023-07-25
2023-07-11
2023-06-27
2023-06-13
2023-05-30
2023-05-16
2023-05-02
2023-04-04
2023-03-21
2023-03-07
2023-02-21
2023-02-07
2023-01-24
2023-01-10
|
| weboftrust-keri-main/5 | weboftrust-keri-main | repository prose file | Apache-2.0 | agenda2022.md | https://github.com/WebOfTrust/keri/blob/main/agenda2022.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/agenda2022.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 67385 | <hr>
tags: KERI, IETF, CommunityKERI Community Meeting Agenda 2022 and earlierChair: Samuel M. Smith email Co-Chair: Philip Feairheller email Meeting Bi-weekly starting on 2021-10-19 at 10 am EDT Agenda: https://hackmd.io/-soUScAqQEaSw5MJ71899w (linked from github but edited in HackMD) Zoom Meeting: https://us02web.zoom.us/j/89842900185?pwd=OEpXSU5pa29FR1A3OXFkUithZFNwQT09 Meeting ID: 898 4290 0185 Passcode: 300255 Calendar Invite: https://us02web.zoom.us/meeting/tZ0lc-uhrjsrEtFmV2aSfAzR015DDL-ld-hg/ics?icsToken=98tyKuGhpj8oE9SVsRGCRpx5Go-ga_PziGJcj7d7kSm3AhNVQxnEZrMXFpZTXdTU KERI Slack: keriworld.slack.com https://join.slack.com/t/keriworld/shared_invite/zt-14326yxue-p7P~GEmAZ65luGSZvbgFAQ Explanation of KERI development tools and techniques: KERI development environment Meetings2022-12-13
2022-11-29
2022-11-01
2022-10-18
2022-10-04
We think this might be a good trade space for facilitating web clients that do not need to store anything and all the heavy lifting is done in the cloud. Clearly, because event generation and verification are happening in the cloud an attacker who successfully attacks the cloud code supply chain can cause mischief by tricking the client into signing events that the client doesn't really want to sign. But that mischief never rises to the level of key compromise.
2022-09-20
2022-09-06
2022-08-23
2022-08-09
2022-07-26
2022-07-12
2022-06-28
2022-06-14
2022-05-31
2022-05-17
2022-05-03
2022-04-19
2022-04-05
DID -> Service : Open service<br> note left DID controller can verify the service provider following same flow of DID Auth (mutal authentication) end note Service -> DID : Ask for DID DID -> Service : Provide DID Service -> DB : Stores DID and generate nounce Service -> DID : Generate challange for given DID note right Challenge include a nounce generated for that specific DID end note DID -> Service : Respond to the challange note left The challenge can be scane via QR, click the link or any other transport. end note note right Respond to the challange includes: - OOBI - Signed challange with private key of the DID controller end note Service -> OOBI : Retrive KEL of given DID Service -> Service : verify challange Service -> DID : Issue session token @enduml ``` 2022-03-22
2022-03-08
2022-02-22
2022-02-08
2022-01-25
2022-01-11
2021-12-14
2021-11-30
2021-11-16Recording - rpy message - d field for said - exp message - d field for said - qry message - d field for said - All keri key event messages icp rot dip drt ixn to add d field for said of message. ( https://github.com/WebOfTrust/keripy/issues/110 ) - p field will be said of prior message - Query Message keriox (michal pietrus) - how handling query and reply - New partial rotation https://github.com/WebOfTrust/keripy/issues/118 - Where we chat in realtime - Issue update readme with status of features 2021-11-02Recording - Call-to-order - Review Licensing Terms and Participation - progress updates from - keripy team - ksn query get the current state existing key for identifier query for KEL to update - escrow query to get BADA (Best Available Data Logic) - HCF team - Leverage time stamping authority point in time that you trust - DIF update nothing new still trying to figure out what to do working group - Sam invite keriox and kerijs to attend this working group - Witness network - clarification of receipts - count code #B indexed witness signatures is more compact than #C which is couplets - #B is useful if many witnesses - Witnesses as highly disposable entities with NonTrans AIDs - Listen on two ports TCP and HTTP - If TCP then assumes direct mode - IF HTTP then assumes indirect mode - Witness Hosts also provide a MailBox service with HTTP SSE (server sent events) - Controller of witnesses subscribes to SSE stream on Mailbox to read responses to its witness queries - Kubernetes pod - HTTP API is wrapper of keripy CESR message and unwraps to send to Parser: HTTP requests to Parsable CESR messages - delegation issues with witnesses https://github.com/WebOfTrust/keripy/issues/100 - - New change to ledger registrars as backers - https://github.com/WebOfTrust/keripy/issues/90 - registrar backer allows some to use a ledger registrar backer and ledger oracle instead of a witness pool as the secondary root of trust. Registrar may also provide an oracle or may have multiple oracles not specified. - Witness KAACE algorithm provides a distributed consensus agreement. - TimeStamp of watchers is authoritative for validator Judge role 2021-10-19
|
| weboftrust-keri-main/6 | weboftrust-keri-main | repository prose file | Apache-2.0 | docs/KERI-Mooc.md | https://github.com/WebOfTrust/keri/blob/main/docs/KERI-Mooc.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/docs/KERI-Mooc.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 202 | Placeholder fileTo offer the right link from KERI.ONE website to KERI-Mooc is a legacy concept. KERISSE is one of the places to enter learning about the KERI Suite. |
| weboftrust-keri-main/7 | weboftrust-keri-main | repository prose file | Apache-2.0 | docs/KERI_Msg_Seal.md | https://github.com/WebOfTrust/keri/blob/main/docs/KERI_Msg_Seal.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/docs/KERI_Msg_Seal.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 16749 | <hr>
tags: KERI email: sam@samuelsmith.org version: 1.01 <hr>KERI Message and Seal FormatsBecause adding the Field LabelsSAIDs and KERI Label Convention NormalizationBecause order of appearance of fields is enforced then where a label appears can add context to help clarify its meansing.
We have two other identifiers that appear after In this context, KERI Defined Element Labels|Label|Description|Type|Notes| |---|---|---|---| |v| Version String| | | |i| Identifier Prefix| | | |s| Sequence Number| | | |t| Message Type| | | |te| Last received Event Message Type in Key State Notice | | | |d| SAID of Event || |p| Prior Event Digest | | | |kt| Keys Signing Threshold || | |k| List of Signing Keys (ordered key set)| | | |n| Next Key Set Commitment | | | |bt| Backer Threshold || | |b| List of Backers (ordered backer set) | | | |br| List of Witnesses to Remove (ordered witness set) | | | |ba| List of Witnesses to Add (ordered witness set) | | | |c| List of Configuration Traits/Modes | | | |a| List of Anchors (seals) || | |da| Delegator Anchor Seal in Delegated Event (Location Seal) | | Obsolete | |di| Delegator Identifier Prefix | | | |rd| Merkle Tree Root Digest || | |ee| Last Establishment Event Map | | | |vn| Version Number ("major.minor") | | | A label may have different values in different contexts but not a different value type. Normalized ACDC Labels
Event MessagesInception EventWhen the AID in the When the AID is not self-addressing, i.e. the
Basic Rotation Event (also delegating rotation)
Partial Rotation Event
Interaction Event (Also delegating Interaction)
Delegated Inception Event```json { "v" : "KERI10JSON00011c_", "t" : "dip", "d" : "E0d8JJR2nmwyYAfZAoTNZH3ULvaU6Z-iSVPzhzS6b5CM", "i" : "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8", "s" : "0", "t" : "dip", "kt": "1", "k" : ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"], "n" : "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM", "bt": "1", "b" : ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"], "c" : ["DND"], "a" : [], "di": "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM" <br> } ``` Basic Delegated Rotation Event
Delegated Partial Rotation Event
ReceiptsNon-Transferable Prefix Signer ReceiptFor receipts the
Transferable Prefix Signer ReceiptFor receipts the
SealsDigest Seal
Merkle Tree Root Digest Seal
Registrar Seal```json { "d" : "EFGKDDA...", "bi": "BACDEFG..." } ``` Event Seal
Other MessagesQuery Message
Reply Message
Expose Message
Exchange Message (exchange)
Notices Embedded in Reply MessagesKey State Notice (KSN)
Embedded in Reply
Transaction State Notice (TSN)
Embedded in Reply
Transaction Event Log MessagesRegistry Inception Event```json { "v" : "KERI10JSON00011c_", "t" : "vcp", "d" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A", "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A", "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8", "s" : "0", "bt": "1",<br> "b" : ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"], "c" : ["NB"] } ``` Registry Rotation Event
Backerless Credential Issuance
Backerless Credential Revocation
Backer Credential Issuance
Backer Credential Revocation
|
| weboftrust-keri-main/8 | weboftrust-keri-main | repository prose file | Apache-2.0 | docs/PartialRotation.md | https://github.com/WebOfTrust/keri/blob/main/docs/PartialRotation.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/docs/PartialRotation.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 10332 | <hr>
tags: KERI, Partial Rotation, Ort email: sam@samuelsmith.org version: 2.02 <hr>Partial Participating RotationNew event definitions with fields to allow rotation that need only expose a threshold set of of the public keys allowing reuse of unexposed public keys. Partion RotationRevised Syntax Next,
|
| weboftrust-keri-main/9 | weboftrust-keri-main | repository prose file | Apache-2.0 | docs/oobi.md | https://github.com/WebOfTrust/keri/blob/main/docs/oobi.md | WebOfTrust / keri-main, https://github.com/WebOfTrust/keri/blob/main/docs/oobi.md. Licensed under the Apache License 2.0; the license and any notices are in the repository. Found through KERISSE. | 21963 | <hr>
tags: KERI, OOBI, Out-Of-Band-Association email: sam@samuelsmith.org version: 1.00 <hr>KERI OOBIVacuous discovery of IP resources such as service endpoints associated with a KERI AID requires an Out-Of-Band Introduction (OOBI) to associate a given URL with a given AID. The principal reason for this requirement is that KERI AIDs are pseudonymous and completely independent of internet and DNS addressing infrastructure. Thus an IP address or URL could be considered a type of Out-Of-Band Infrastructure (OOBI) for KERI. In this context an introduction is an association between a KERI AID and a URL which may include either an explicit IP address for its netloc or a DNS name. We call this a KERI OOBI (Out-Of-Band-Introduction) and is a special case of Out-Of-Band-Infrastructure (OOBI) with a shared acronym. For the sake of clarity, unless otherwise qualified, OOBI is used to mean this special case of an introduction and not the general case. Moreover, because IP infrastructure is not trusted by KERI, a KERI OOBI by itself is considered insecure with respect to KERI and any OOBI must therefore be later proven and verified using a KERI BADA (Best Available Data Acceptance) mechanism. The principal use case for an OOBI is to jump start the discovery of a service endpoint for a given AID. To reiterate, the OOBI by itself is not sufficient for discovery because the OOBI itself is insecure. The OOBI merely jump starts authenticated discovery. Using IP and DNS infrastructure to introduce KERI AIDs which AIDs are then securely attributed allows KERI to leverage IP and DNS infrastructure for discovery. KERI does not therefore need its own dedicated discovery network, OOBIs as URLs will do. The simplest form of a KERI OOBI is a namespaced string, a tuple, a mapping, a structured message, or structured attachment that contains both a KERI AID and a URL. The OOBI associates the URL with the AID. In tuple form this abstractly:
An OOBI itself is not signed or otherwise authenticatible by KERI but may employ some other Out-Of-Band-Authentication (OOBA) mechanism (non-KERI). The OOBI is intentionally simplistic to enable very low byte count introductions such as a QR code or Data matrix or the like. A recipient of an OOBI authenticates authorized endpoints for the AID in the OOBI by querying the OOBI URL. The URL resource responds with supporting BADA reply messages that are KERI authenticatable. Multi-OOBI (MOOBI)An OOBI may include a list of URLs thus simultaneously making an introductory association between the AID and multiple URLs. This would be a multi-OOBI (MOOBI). In general we may refer to a multi-OOBI as a special case of an OOBI without making a named distinction. OOBI as URL (iurl)URLs provide a namespace which means that the mapping between URL and AID can be combined into one namespaced URL where the AID is in the path component and any other hints such as roles or names are in the query component of the URL. This would be a type of self-describing OOBI URL. For example suppose the
The aid may act in any of the KERI roles such as
When the role is provided in the To clarify, the minimum information in an OOBI is pair, Other Forms of OOBIsWell-KnownAn OOBI may be returned as the result of a get request to an IETF RFC 5785 well-known URL. For example:
or
or
The resultant target URL may be in a different domain or IP address from the well known resource. Full CID and EIDA more verbose version would also include the endpoint role and the AID (EID) of the endpoint provider in the self describing OOBI URL.
Where KERI Reply Messages as OOBIsA more verbose expression for an OOBI would be a KERI reply message
A service endpoint location reply message could also be re-purposed as an OOBI by using a special route path that includes the AID being introduced and optionally the role of the service endpoint provider as follows:
This more verbose approach includes the AID (EID) of the service endpoint provider which may allow a short cut to authenticating the service endpoint. Self and Blind IntroductionsA bare URL but no AID may be used as a bare OOBI for blind or self introductions. Querying that bare OOBI may return or result in a default target OOBI or default target endpoint reply. This provides a mechanism for self-introduction, i.e. self OOBI (SOOBI). Consider a bare OOBI as follows:
By default the result of get request to this OOBI URL could be another OOBI with an AID that is the This may be especially useful to bootstrap components in an infrastructure where the target URLs do not use a public DNS address but use instead something more secure like an explicit public IP address or a private IP or private DNS address. A self introduction provides a bootstrap mechanism similar to a hostname configuration file with the exception that in the OOBI case the AID is not in the configuration file just the bare OOBI URL and the given node queries that bare OOBI to get the target endpoint AID. This allows bootstrap using bare IP addresses in systems where the IP infrastructure is more securely managed than public DNS or where some other Out-Of-Band-Authentication (OOBA) mechanism is used in concert. Because the OOBI itself does not contain an AID the association of the resultant AID is not provided by the OOBI and the resultant AID's association must be secured by some other mechanism. For example a given indirect mode controller is identified by its AID (CID). The controller must also create witness hosts with endpoints. This means first spinning up witness host nodes and creating witness AIDs (WIDs) for those nodes. Given that these WIDs must be eventually designated in the KEL for the CID, the controller of the CID can confirm using its KEL that the signed endpoint reply provided by a bare OOBI request is indeed signed by the corresponding private keys for a WID designated in its KEL. This means that the only place that the WID must appear is in the KEL and not in all the config files used to boostrap communications between the CID host and its designated WID hosts. Bare OOBIs will do. Redundant configuration information may be a vector for a type of DDOS attack where corrupted inconsistent redundant configuration information results in a failure to boot a system that must be manually fixed. Redundancy for security is best applied in the context of a self-healing or resilient threshold structure that explicitly manages the redundancy as a security mechanism not as un-managed inadvertent redundancy. Equivalently a bare OOBI (no AID) provides a mechanism for blind introductions, i.e. a blind or bare OOBI (BOOBI). Because the OOBI does not expose an AID, the the resultant response when querying the OOBI may depend on other factors such as the source IP of the querier (requester) and/or another out-of-band-authentication (OOBA) mechanism. This supports private bootstrap of infrastructure. Of course one could argue that this is just kicking the can down the road but IP addresses are correlatable and a blind OOBI can leverage IP infrastructure for discovery when useful in combination with some other OOBA mechanism without unnecessary correlation. OOBI ForwardingIn every case an OOBI may result in a proof for a different URL than that provided in the OOBI itself. The allows OOBI forwarding so that introductions produced as hard copies such as QR codes do not necessarily become stale. The recipient of the OOBI may choose to accept that proof or not. Ultimately the recipient only treats URLs as valid endpoints when they are fully KERI authenticated. Given that an OOBI result is always KERI authenticated before use in a given role, the worst case from a security perspective is that an OOBI may be part of a DDOS attack but not as part of a service endpoint cache poison attack. OOBI KERI Endpoint Authentication (OKEA)Upon acceptance of an OOBI the recipient queries the provided URL for proof that the URL is an authorized endpoint for the given AID. The proof format may depend on the actual role of the endpoint. A current witness for an AID is designated in the current key state's latest establishment event in the AID's KEL. Therefore merely replying with the Key State or KEL may serve as proof for a witness introduced by an OOBI. Other roles are not part of key state (i.e. are not designated in KEL establishment events) and therefore must be authorized by another mechanism. This typically will be a signed /end/role/ reply message. So the query of the OOBI URL could return as proof an associated authorizing reply message. For example: ```json { "v" : "KERI10JSON00011c_", "t" : "rpy", "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM", "dt": "2020-08-22T17:50:12.988921+00:00", "r" : "/end/role/add", "a" : { "cid": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM", "role": "watcher", "eid": "BrHLayDN-mXKv62DAjFLX1_Y5yEUe0vA9YPe_ihiKYHE", } } ``` OOBI with MFAAn OOBI may be augmented with one or more Out-Of-Band Authentications (OOBAs) to minimize the likelihood of a DDOS OOBI attack. A given recipient may require as a precondition to accepting an OOBI one or more OOBA mechanisms such as text messages, emails, etc that together provide some degree of non-KERI based security to the OOBI. Thus an OOBI could employ out-of-band (with respect to KERI) multi-factor-authentication (MFA) to preclude any OOBI based DDOS attacks on KERI. KERI OOBI Use in Installation ConfigurationOOBI DiscoveryThe main value of an OOBI is that it is compact and is not encumbered by authentication proofs but may be used to kick-start the process of authentication (proving). One way to pre-configure a vacuous KERI installation is to provide OOBIs in a configuration file. The bootstrap process of the installation then queries the associated URLs to retrieve the KERI authentication proofs (BADA) that then are used to populate its database securely. This simplifies the configuration file. In contrast, an alternative would be to populate the configuration file with the KERI authentication proofs. But these proofs may be quite verbose and cumbersome and may make the config file somewhat difficult to manage in human readable/writable form. Furthermore if one already had the proofs one could just pre-populate the database with those proofs. Therefore OOBI based configuration fiels may be advantageous as either easier to manage and as a viable option when the proofs are not yet available at configuration time. Furthermore a clean clone replay restart of a given KERI component is designed to fix any unverified corruption of its associated KELs. If each component uses OOBIs to retrieve the authentication proofs from other components then all the components will have the cleaned proofs instead of stale proofs. OOBI ResponseEach KERI installation may also optionally provide an OOBI permissioning record list associated with each habitat to indicate which OOBI queries it will respond to. This may also be inited with a config file. AddendumThis is an attempt to provide configuration information to an agent to enhance the current OOBI resolution process with a well known verification process for multi-factor authentication of an AID provided by an OOBI in the configuration file. This process will be used in the vLEI ecosystem configuration files to bootstrap resolution and authentication of the GLEIF RoOT and GLEIF External AIDs for all agents in the ecosystem. The proposed approach would be to add a new top level key to the configuration file (murls or wurls) that contains a list of well-known OOBIs with AIDs. The OOBI resolution process would be updated such that after the successful resolution of endpoints for an AID from an OOBI URL in the iurls section, the system would scan the well-known URLs in array in this new key for all URLs that contain the AID just resolved. The system would then resolve each URL by making a successful HTTP request against that URL. A successful HTTP request would be one that returns either a 2xx or 3xx HTTP status code. After successfully resolving all URLs for the AID, the system would make the contact created for the new AID with a new authenticated status. Currently, the Keep software sets a verified field to True after a successful 12-word challenge response has been received from the AID that was just resolved with an OOBI. To accommodate this new method of multi-factor authentication, we would change the field name on the contact to authenticated and change the value from boolean to a status value representing the type of authentication that was performed. In addition, we would add an authenticated_date field to the contact to indicate the date and time on which any MFA was performed. The proposed status values are SIGNED_CHALLENGE for the current Keep challenge / response authentication and WELL_KNOWN for the new well-known resolution challenge response. Given the following configuration file: { "dt": "2022-01-20T12:57:59.823350+00:00", "iurls": [ "http://127.0.0.1:5642/oobi/BBilc4-L3tFUnfM_wJr4S4OJanAv_VmF_dJNN6vkf2Ha/controller", "http://127.0.0.1:5644/oobi/BIKKuvBwpmDVA4Ds-EpL5bt9OqPzWPja2LigFYZN2YfX/controller", "http://127.0.0.1:5643/oobi/BLskRTInXnMxWaGqcpSyMgo0nYbalW99cGZESrz3zapM/controller", "http://20.121.171.161:7723/.well-known/keri/oobi/EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG?name=GLEIF%20Root" ], "durls": [ "http://127.0.0.1:7723/oobi/EIL-RWno8cEnkGTi9cr7-PFg_IXTPx9fZ0r9snFFZ0nm", "http://127.0.0.1:7723/oobi/EJEMDhCDi8gLqtaXrb36DRLHMfC1c08PqirQvdPPSG5u", "http://127.0.0.1:7723/oobi/EDqjl80uP0r_SNSp-yImpLGglTEbOwgO77wsOPjyRVKy", "http://127.0.0.1:7723/oobi/EOhcE9MV90LRygJuYN1N0c5XXNFkzwFxUBfQ24v7qeEY", "http://127.0.0.1:7723/oobi/EK0jwjJbtYLIynGtmXXLO5MGJ7BDuX2vr2_MhM9QjAxZ", "http://127.0.0.1:7723/oobi/ED_PcIn1wFDe0GB0W7Bk9I4Q_c9bQJZCM2w7Ex9Plsta", "http://127.0.0.1:7723/oobi/ELqriXX1-lbV9zgXP4BXxqJlpZTgFchll3cyjaCyVKiz" ], "murls": [ "https://www.gleif.org/.well-known/keri/oobi/EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG", "https://github.io/WebOfTrust/vLEI/.well-known/keri/oobi/EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG", "https://github.io/GLEIF-IT/vLEI/.well-known/keri/oobi/EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG", "https://www.first-roc-member.com/.well-known/keri/oobi/EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG", "https://www.another-roc-member.com/.well-known/keri/oobi/EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG" ] } The resolution of the OOBI for AID EL0QKj5uCRRAawr91sVWCVvKM1XNMQ3WJGo_g0O9s-BG from the iurls array (the last one in the list) would result in a redirect to a witness or controller endpoint that would be saved in the database and associated with the contact with the alias “GLEIF Root”. After completion, the system would scan the array at the key murls and find 5 well-known URLs that contain the AID just resolved. If would perform an HTTP GET request on each URL in turn and if every URL results in a 2xx or 3xx status code it would update the contain for the new AID to the following (JSON representation): { "alias": "GLEIF Root", "authenticated": "WELL_KNOWN", "authenticated_date": "2022-10-02T12:57:59.823350+00:00" } Nothing would prevent the controller of the agent using this configuration file to perform a 12-word challenge / response protocol with the new AID in the future and updating the values in the contact with a new authenticated status and new date in authenticated_date. In this way the controller can leverage the MFA provided in the configuration file but later upgrade the authentication by engaging in a live session challenge. Consideration was given to allowing for a threshold to be specified for indicating how many URLs in the murls key need to succeed for a given AID for it to be considered authenticated. Since the configuration file is under the control of the distributors of the software, stale values will not affect controllers that have already authenticated the AIDs during their initial start up. There is no need to allow for permanent failures of well known URLs because they can be removed from the configuration file for any new installations of the software. Controllers with older versions will have already performed the initial set up and no longer need a full set of valid well knowns. Temporary failure of well knowns can be accounted for with a simple retry mechanism that is already in place for all OOBI resolutions. This method can be extended in the future to allow for both a command line version of well known authentication as well as agent based verification. All that would be required is additions to the current kli oobi resolve command to include specifying a list of urls (multi-option collection) as an option to the command as well as an addition key pointing to an array in the body of the POST /oobi endpoint in the agent. Samuel Smith 10/03/22 Suggest that the authenticated field value could be a list so that both WELL_KNOWN and SIGNED_CHALLENGE types of authentication could be applied to the same AID and not either or. In the future other types of authentication could then be supported. Samuel Smith 31m Just noticed that I could not find any documentation of the field labels in the config file .json I know we discussed these someplace but couldn’t find it. So we should create a json schema for config files that in the description field of each label defines what the label means |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE document_text (id TEXT PRIMARY KEY, source_id TEXT, kind TEXT, license TEXT, title TEXT, url TEXT,
credit TEXT, chars INTEGER, text TEXT);