xdi tcs
This commit is contained in:
⧉ infominer
parent
7228296545
commit
fe506f901a
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
date: 2019-03-15
|
||||
title: XDI - XRI Data Interchange
|
||||
title: XDI (XRI Data Interchange)
|
||||
excerpt: >
|
||||
XDI is a technology for modeling, storing, and manipulating data.
|
||||
|
||||
|
|
@ -9,15 +9,18 @@ excerpt: >
|
|||
XDI is a graph-based data model. This means that all data is expressed using nodes and arcs in a graph. At a minimum, a graph consists of a single node, called the common root node.
|
||||
description: "XDI is a graph-based data model. This means that all data is expressed using nodes and arcs in a graph. At a minimum, a graph consists of a single node, called the common root node."
|
||||
layout: single
|
||||
permalink: /web-standards/xdi/
|
||||
canonical_url: 'https://decentralized-id.com/specs-standards/xdi/'
|
||||
permalink: web-standards/oasis-open/xdi/xdi/
|
||||
canonical_url: 'https://decentralized-id.com/web-standards/oasis-open/xdi/xdi/'
|
||||
redirect_from:
|
||||
- /specs-standards/xdi/
|
||||
- web-standards/xdi/
|
||||
- specs-standards/xdi/
|
||||
- standards/xdi
|
||||
- standards/xdi/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["XDI","Danube Tech","OASIS","BTCR","W3C","Planetwork"]
|
||||
last_modified_at: 2019-03-15
|
||||
header:
|
||||
teaser: /images/xdi-teaser.webp
|
||||
last_modified_at: 2020-12-01
|
||||
---
|
||||
|
||||
* [tutorial.xdi2.org](https://tutorial.xdi2.org)
|
||||
|
|
@ -38,6 +41,11 @@ The XNS Public Trust Organization was founded in July 2000, shortly after Intern
|
|||
>
|
||||
> XDI is a graph-based data model. This means that all data is expressed using nodes and arcs in a graph. At a minimum, a graph consists of a single node, called the common root node.
|
||||
|
||||
* [The Dataweb: An Introduction to XDI](https://www.oasis-open.org/committees/download.php/6434/wd-xdi-intro-white-paper-2004-04-12.pdf) - A White Paper for the OASIS XDI Technical Committee v2, *April 12, 2004*
|
||||
> XDI (XRI Data Interchange) is a new service for generalized distributed data sharing and mediation usingXRIs (Extensible Resource Identifiers), a URI-compatible abstract identifier scheme developed by the OASIS XRI Technical Committee. The goal of XDI is to enable data from any data source to be identified, exchanged, linked, and synchronized into a machine-readable dataweb using XML documents just as content from any content source can linked into the human-readable Web using HTML documents today. Because the controls needed to mediate access and usage of shared data can be built right into every XDI link, the emergence of a global Dataweb has the potential to do for trusted data interchange what the Web did for open content exchange.
|
||||
>
|
||||
> This white paper presents several examples of classic cross-domain data sharing problems, explains how the Dataweb model can provide a generalized solution, and describes the key objectives of the newlyformed OASIS XDI Technical Committee ([http://www.oasis-open.org/committees/xdi](http://www.oasis-open.org/committees/xdi)).
|
||||
|
||||
|
||||
## RWoT Papers
|
||||
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
---
|
||||
date: 2020-12-01
|
||||
title: XRI Technical Committee
|
||||
description: Defining a syntax for abstract structured identifiers to share semantics across different URI schemes, domains, and applications (XRI); plus defining a simple XML format for uniform metadata discovery for all URIs (XRD)
|
||||
excerpt: >
|
||||
The purpose of this TC is to define a syntax for abstract structured identifiers -- identifiers that can be used within other URI schemes (such as http: and https: URIs) to share semantics across any number of domains and applications. The TC is also defining a simple XML descriptor format and HTTP(S) protocol for uniform resource metadata discovery.
|
||||
category: ["Web Standards"]
|
||||
tags: ["OASIS","XRI","XDI","Dataweb"]
|
||||
last_modified_at: 2020-12-01
|
||||
permalink: web-standards/oasis-open/xdi/xdi-tc/
|
||||
canonical_url: https://decentralized-id.com/web-standards/oasis-open/xdi/xdi-tc/
|
||||
toc: false
|
||||
header:
|
||||
image: /images/xri-tc-header.webp
|
||||
teaser: /images/xdi-teaser.webp
|
||||
|
||||
---
|
||||
|
||||
**[OASIS Extensible Resource Identifier (XRI) TC](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri)**
|
||||
|
||||
* [An Introduction to XRIs](https://docs.oasis-open.org/xri/xri/V2.0/xri-intro-V2.0.pdf)
|
||||
> - XRIs provide a uniform syntax and resolution protocol for both persistent and reassignable abstract identifiers.
|
||||
> - XRIs provide a uniform syntax for delegating abstract identifiers between authorities at any level or context.
|
||||
> - XRIs provide a uniform syntax (called “cross-references”) for sharing abstract identifiers across all contexts.
|
||||
> - XRIs provide both a generic and a trusted protocol for resolving a single abstract identifier into any number of concrete identifiers.
|
||||
> - XRIs provide a simple, standard means of discovering URIs that may be associated with a resource, including those needed for additional metadata discovery.
|
||||
> - XRIs provide a standard means of protecting privacy by revealing the least possible information in an identifier and allowing an authority to control further access.
|
||||
> - XRIs provide a standard means of extension without sacrificing interoperability.
|
||||
* [XDI FAQ](https://www.oasis-open.org/committees/xdi/faq.php)
|
||||
> **_What features do XRIs have that URIs don't?_**
|
||||
> - **XRIs are "location-independent"** - the content of an XRI is decoupled from the network location of any data or services associated with the XRI. This means, among other things, that accessing a resource associated with an XRI isn't limited to a particular network location or protocol. (Most URI schemes in wide use today use identifiers that imply a close association to a network location or protocol.)
|
||||
> - **XRIs can assert persistence of all or parts of an identifier**. XRIs allow two types of separators (persistent and reassignable) between segments of an XRI, so the XRI can suggest that certain parts of the identifier are intended to be long-lived "primary keys" (a concept borrowed from database technology) and others are subject to change. Most URI schemes, on the other hand, are all-or-nothing. With URNs, for example, the entire identifier is persistent. With HTTP URIs, the entire identifier is potentially transient. The XRI scheme allows both characteristics to be combined in one federated identifier.
|
||||
> - **XRIs provide the ability to "contain" other URIs or XRIs in the form of cross-references**. Conceptually this is similar to using quote marks in English to talk about someone else's text. Cross references allow a well-defined URI or XRI to identify not only a concept or resource, but also to identify that concept or resource relative to another concept or resource. For example, a URI could identify a book, and an XRI could then identify a particular library's copies of the book by using that URI in a cross-reference appended to the library's XRI. So if " urn:isbn:0-131-10362-8" represents The C Programming Language by Kernighan and Ritchie, and "xri:@SeattlePublicLibrary" represents the Seattle Public Library, then "xri:@SeattlePublicLibrary/(urn:isbn:0-131-10362-8) " represents The C Programming Language in the context of the Seattle Public Library.
|
||||
> - **XRIs also support self-references**, a special form of cross-reference that indicates that an XRI is not intended to be resolved on the network but is intended solely as a unique identifier. For example, "xri:(@SeattlePublicLibrary/(urn:isbn:0-131-10362-8))" is a self-reference because it is entirely enclosed by parentheses, and as such represents the identifier itself.
|
||||
> - **XRIs allow unlimited delegation of namespaces**. While many URI schemes rely on DNS delegation, XRIs also have the ability to use abstract (non-DNS) names or identifiers that can contain a wider set of characters and strings. The XRI specification includes several global context symbols for this purpose (e.g., the "@" in "xri:@example/foo" represents a standard global namespace for organizations). In addition, a cross-reference can also serve as a namespace root, thus creating a private or community-based identifier space whose management is entirely community defined (for example, "xri:(http://www.example.com)/foo").
|
||||
> - **XRIs are fully internationalized**. XRI syntax builds on the W3C IRI (Internationalized Resource Identifier) specifications that adapt URIs to the Unicode character set.
|
||||
* [Extensible Resource Identifier (XRI) Syntax V2.0](http://www.oasis-open.org/committees/download.php/5109/xri-syntax-resolution-1.0-cd.pdf) - Committee Specification, 14 November 2005
|
||||
> Extensible Resource Identifiers (XRIs) provide a standard means of abstractly identifying a resource independent of any particular concrete representation of that resource—or, in the case of a completely abstract resource, of any representation at all.
|
||||
>
|
||||
> As shown in Figure 1, XRIs build on the foundation established by URIs (Uniform Resource Identifiers) and IRIs (Internationalized Resource Identifiers) as defined by [URI] and [IRI], respectively.\
|
||||
> \
|
||||
> The IRI specification created a new identifier by extending the unreserved character set to include characters beyond those allowed in generic URIs. It also defined rules for transforming this identifier into a syntactically legal URI. Similarly, this specification creates a new identifier, an XRI, that extends the syntactic elements (but not the character set) allowed in IRIs. To accommodate applications that expect IRIs or URIs, this specification also defines rules for transforming an XRI reference into a valid IRI or URI reference.
|
||||
* [Extensible Resource Identifier (XRI) Metadata V2.0](https://www.oasis-open.org/committees/download.php/11854/xri-metadata-V2.0-cd-01.pdf)
|
||||
> [XRISyntax] establishes five global context symbol (GCS) characters that may be used to begin an XRI authority segment for the purpose of expressing the abstract global context of an identifier. One of these GCS characters, "$", is reserved for identifiers for which the authority is a standards specification.
|
||||
>
|
||||
> A second key XRI feature, cross-references (see section 2.2.2 of [XRISyntax]), allows XRIs to be embedded within other XRIs in order to share identifiers across contexts. This syntactic feature allows XRIs in the $ namespace to be used as metadata to describe an XRI itself. For example, the following XRI includes a cross-reference with version metadata.
|
||||
> ```
|
||||
> xri://@example*resource*($v/3)
|
||||
> \----/ cross-reference with XRI metadata
|
||||
> ```
|
||||
> The purpose of this specification is to define a set of XRIs in the $ namespace that function as identifier metadata—attributes that may be used describe an identifier itself, as opposed to attributes of the resource it identifies. This specification defines four such types of identifier metadata:
|
||||
> - Language metadata that specifies the human language in which an identifier is intended to be interpreted.
|
||||
> - Date/time metadata that specifies the point in time an identifier was established.
|
||||
> - Version metadata that specifies the identifier’s position in a sequence of identifiers for the same logical resource.
|
||||
> - Annotation metadata that allows XRI producers to add annotations to XRIs or XRI segments.
|
||||
> The definition of each metadata type also specifies comparison rules, significance in resolution, and any other special processing rules specific to that type.
|
||||
* [Extensible Resource Identifier (XRI) Resolution Version 2.0](https://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/xri-resolution-V2.0-cs-01.pdf)
|
||||
> Extensible Resource Identifier (XRI) provides a uniform syntax for abstract structured identifiers as defined in [XRISyntax]. Because XRIs may be used across a wide variety of communities and applications (as Web addresses, database keys, filenames, object IDs, XML IDs, tags, etc.), no single resolution mechanism may prove appropriate for all XRIs. However, in the interest of promoting interoperability, this specification defines a simple generic resource description format called XRDS (Extensible Resource Descriptor Sequence), a standard protocol for requesting XRDS documents using HTTP(S) URIs, and standard protocol for resolving XRIs using XRDS documents and HTTP(S) URIs. Both generic and trusted versions of the XRI resolution protocol are defined (the latter using HTTPS [RFC2818] and/or signed SAML assertions [SAML]). In addition, an HTTP(S) proxy resolution service is specified both to provide network-based resolution services and for backwards compatibility with existing HTTP(S) infrastructure.
|
||||
>
|
||||
> | Resolution Component | DNS Architecture | XRI Architecture |
|
||||
> | --- | --- | --- |
|
||||
> | Identifier | domain name | XRI (authority + path + query) |
|
||||
> | Resource record format | text (resource record) | XML (XRDS document) |
|
||||
> | Attribute identifier | string | anyURI |
|
||||
> | Network endpoint identifier | IP address | URI |
|
||||
> | Synonyms | CNAME | LocalID, EquivID, CanonicalID, CanonicalEquivID |
|
||||
> | Primary resolution protocol | UDP | HTTP(S) |
|
||||
> | Trusted resolution options | DNSSEC | HTTPS and/or SAML |
|
||||
> | Resolution client | resolver | resolver |
|
||||
> | Resolution server | authoritative nameserver | authority server |
|
||||
> | Recursing resolution | recursing nameserver | recursing authority server or proxy resolver |
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
---
|
||||
date: 2020-12-01
|
||||
title: XDI Technical Committee
|
||||
description: XDI is a format and protocol for semantic data interchange -- a way different systems, applications, and databases can describe, map, exchange, link, synchronize, and protect data using a shared semantic graph model.
|
||||
excerpt: >
|
||||
The purpose of the OASIS XDI TC is to define a generalized, extensible, location-, application-, and transport-independent service for sharing, linking, and synchronizing data over the Internet and other data networks using XML documents and XRIs (Extensible Resource Identifiers), a URI-compatible abstract identifier scheme defined by the OASIS XRI Technical Committee. With XDI, data from any data source can be identified, described, linked, and synchronized into an active, machine-readable "dataweb" just as content from any content source can be identified and linked into the human-readable Web today.
|
||||
category: ["Web Standards"]
|
||||
tags: ["OASIS","XRI","XDI","RDF","Dataweb"]
|
||||
permalink: web-standards/oasis-open/xdi/xri-tc/
|
||||
canonical_url: https://decentralized-id.com/web-standards/oasis-open/xdi/xri-tc/
|
||||
last_modified_at: 2020-12-01
|
||||
header:
|
||||
image: /images/xdi-tc-header.webp
|
||||
teaser: /images/xdi-teaser.webp
|
||||
toc: false
|
||||
---
|
||||
|
||||
**[GitHub](https://github.com/OASIS-XDI-Technical-Committee/) • [OASIS XRI Data Interchange (XDI) TC](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xdi)**
|
||||
|
||||
> The Technical Committee was closed by OASIS TC Administration on 05 October 2020 and is no longer active. Archives of its work remain publicly accessible and are linked from this page. OASIS appreciates the efforts of all those who participated in this TC.
|
||||
|
||||
* [OASIS Members Form XRI Data Interchange (XDI) Technical Committee](http://xml.coverpages.org/ni2004-01-21-b.html)
|
||||
> A particular purpose of XDI is to allow the controls needed to mediate access and usage of shared data to be expressed as XDI links. These data sharing controls can govern authority, authentication, authorization, access control, usage control, transmission, synchronization, and rights management. The integration of such controls into a common, generalized data-oriented service can provide a new platform for trusted data sharing networks and applications."
|
||||
* [OASIS TC Call For Participation: OASIS XDI TC](https://lists.oasis-open.org/archives/tc-announce/200401/msg00002.html) - Wed, *21 Jan 2004*
|
||||
> The purpose of the OASIS XDI TC is to define a generalized, extensible, location-, application-, and transport-independent service for sharing, linking, and synchronizing data over the Internet and other data networks using XML documents and XRIs (Extensible Resource Identifiers), a URI-compatible abstract identifier scheme defined by the OASIS XRI Technical Committee. With XDI, data from any data source can be identified, described, linked, and synchronized into an active, machine-readable "dataweb" just as content from any content source can be identified and linked into the human-readable Web today.
|
||||
* [OASIS XRI Data Interchange (XDI) TC - Charter](https://www.oasis-open.org/committees/xdi/charter.php)
|
||||
> As a data sharing service, XDI is intended to be very simple and generalized, so it can be bound to any transport protocol offering basic primitives like HTTP or SMTP. Similarly, the XDI graph model is intended to be very simple and generalized, so it can carry data directly (serialized in XML, JSON, or other formats) or reference it externally (much as XML or HTML documents can carry content directly or reference it externally). Such a "lingua franca" for data interchange can solve many problems related to mapping and sharing of data and metadata across domains, directories, schemas, ontologies, applications, and languages (both human and machine).
|
||||
>
|
||||
> Though the potential uses of XDI are very broad, the scope of the OASIS XDI TC work is limited to defining the specifications required for it to interoperate successfully. This includes:
|
||||
>
|
||||
> - Defining the XDI graph model for describing and linking XRI-identified resources and data.
|
||||
> - Defining concrete serialization formats for this graph model.
|
||||
> - Defining rules for XRI addressing of XDI documents and the graphs they contain independent of serialization format.
|
||||
> - Defining an abstract XDI API consisting of logical operations on the XDI graph.
|
||||
> - Defining bindings of this abstract API to concrete transport protocols such as HTTP, SMTP, SIP, and XMPP, and to invocation protocols such as SOAP, REST, and RMI.
|
||||
> - Defining the semantics of XDI dictionaries — self-describing ontologies for use in XDI data sharing.
|
||||
> - Defining the semantics of XDI link contracts — XDI documents used to govern the terms of XDI data sharing relationships.
|
||||
> - Defining the semantics of other types of XDI graphs that fulfill general interoperability requirements of XDI infrastructure, e.g., context discovery, versioning, queries, etc.
|
||||
> - Maintaining additional versions of these specifications as they evolve over time.
|
||||
* [OASIS XRI Data Interchange (XDI) TC - FAQ](https://www.oasis-open.org/committees/xdi/faq.php)
|
||||
> 1. **_What is XDI?_**\
|
||||
> Specifically, XDI consists of three parts:
|
||||
> - The **XDI Meta-Schema-a** very simple XML schema that uses XRIs (Extensible Resource Identifiers) developed by the OASIS XRI TC to describe and link data that may be in many other native formats, including other XML schemas.
|
||||
> - **XDI Service**: a WSDL-defined protocol for exchanging data and metadata using XDI documents, together with bindings to different transport protocols (HTTP, SOAP, SMTP/MIME, etc.)
|
||||
> - The **XDI Service Dictionary**: a set of pre-defined XDI resources for describing other XDI resources and controlling XDI data interchange using XDI link contracts (see below).
|
||||
> 2. **_Is XDI a Web service?_**\
|
||||
> XDI over SOAP is a Web service. However XDI can also be bound to HTTP for use in "RESTful" architectures, as well as to other transport protocols like SMTP/MIME. So strictly speaking XDI is a generalized service based on XML document exchange that can be implemented as a Web service.
|
||||
> 3. **_What are the primary problems XDI is intended to solve?_**\
|
||||
> The general problem XDI is designed to address is interoperable, automated data interchange across distributed applications and trust domains. There are many specific examples of this problem:
|
||||
> - Exchange, linking, and lifetime synchronization of electronic business cards, public keys, and other common identity attributes across distributed directories (commonly known as dynamic address books).*
|
||||
> - Internet calendar sharing.*
|
||||
> - Trusted search (searches that need to cross multiple private websites).*
|
||||
> - Auto-configuration and intelligent data synchronization across multiple user devices (desktop, laptop, PDA, land phone, cell phone, etc.)
|
||||
> - Automated website registration, form-fill, and e-commerce transactions.
|
||||
Cross-domain security and privacy management.
|
||||
> 4. **What is the Dataweb?**\
|
||||
> The inspiration for XDI was the application of the architectural principles of the Web and XML to the problem of distributed data sharing. The result is called the Dataweb, as summarized in the table below:
|
||||
>
|
||||
> | Principle | World Wide Web | Dataweb |
|
||||
> |---|---|---|
|
||||
> | 100% addressable resources | URIs | XRIs |
|
||||
> | Common representation and linking language | HTML | XDI Meta-Schema & XDI Service Dictionary |
|
||||
> | Common interchange protocol | HTTP | XDI/HTTP, XDI/SOAP |
|
||||
> | Logical organization and navigation of resources | Website | Dataweb site |
|
||||
>
|
||||
> In essence, the XDI meta-schema and protocol is to sharing and linking machine-readable data what HTML and HTTP are to sharing and linking human-readable content. In particular, Dataweb links are can define and control two-ways data sharing "pipes" between dataweb sites that can actively synchronize shared data when it changes, as illustrated below.
|
||||
> 5. **Why is existing URI syntax not sufficient for cross-domain data sharing?**
|
||||
>
|
||||
> While URIs in general, and HTTP URIs (commonly called URLs) in particular, have been spectacularly successful for building the Web, they are missing several features that are vital for cross-domain data sharing:
|
||||
>
|
||||
> - HTTP URIs do not provide absolute addressability of data instances down to any level of containment or nesting-they work only to the page or page fragment level. While XPath provides additional addressing features for XML documents, it operates only relative to XML document roots and is not integrated with HTTP URI syntax.
|
||||
> - HTTP URIs do not provide support for persistent addresses (the Dataweb equivalent of global foreign keys in databases). Other persistent URI schemes have been created, most notably the URN scheme, however they are not integrated with HTTP URI syntax and have not gained widespread adoption.
|
||||
> - HTTP URIs do not provide addressability of resources across contexts, i.e., the ability to share identifiers across multiple websites in order to identify the same logical resource in multiple domains or physical locations. This is extremely useful for cross-domain data sharing.
|
||||
* [The Dataweb: An Introduction to XDI](https://www.oasis-open.org/committees/download.php/6434/wd-xdi-intro-white-paper-2004-04-12.pdf) - A White Paper for the OASIS XDI Technical Committee v2, *April 12, 2004*
|
||||
> XDI (XRI Data Interchange) is a new service for generalized distributed data sharing and mediation usingXRIs (Extensible Resource Identifiers), a URI-compatible abstract identifier scheme developed by the OASIS XRI Technical Committee. The goal of XDI is to enable data from any data source to be identified, exchanged, linked, and synchronized into a machine-readable dataweb using XML documents just as content from any content source can linked into the human-readable Web using HTML documents today. Because the controls needed to mediate access and usage of shared data can be built right into every XDI link, the emergence of a global Dataweb has the potential to do for trusted data interchange what the Web did for open content exchange.
|
||||
>
|
||||
> This white paper presents several examples of classic cross-domain data sharing problems, explains how the Dataweb model can provide a generalized solution, and describes the key objectives of the newlyformed OASIS XDI Technical Committee ([http://www.oasis-open.org/committees/xdi](http://www.oasis-open.org/committees/xdi)).
|
||||
* [The Cover Pages topic on Data Sharing, Mediation, and Synchronization](http://xml.coverpages.org/dataSharing.html) Robin Cover's overview of the context in which XDI is being developed.
|
||||
> sample references are being collected for a broad range of topics relating to Web architecture, including notions of resource/object identity, resource identification schemes, persistence, namespaces, naming authorities, registration authorities, name resolution, network protocols, content negotiation, bindings, resource description, metadata, addressing and linking, automated data synchronization, access control, trust management, etc.
|
||||
|
||||
## [OASIS XDI TC Technical Committee Wiki](https://wiki.oasis-open.org/xdi/)
|
||||
|
||||
> - [The XDI Graph Model](https://wiki.oasis-open.org/xdi/XdiGraphModel) - contains links to introductory materials explaining XDI and the XDI graph model
|
||||
> - [XDI Design Goals](https://wiki.oasis-open.org/xdi/XdiDesignGoals) - The ten major design goals for the XDI graph model and semantic data interchange protocol
|
||||
> - [XDI ABNF](https://wiki.oasis-open.org/xdi/XdiAbnf) - formal ABNF rules defining the XDI graph model
|
||||
> - [XDI Serialization Formats](https://wiki.oasis-open.org/xdi/SerializationFormats) - the JSON serialization formats (and 2 text display formats) for XDI
|
||||
> - [XDI Messages](https://wiki.oasis-open.org/xdi/XdiMessagePatterns) - the basic patterns for XDI messaging
|
||||
> - [XDI Dictionaries](https://wiki.oasis-open.org/xdi/XdiDictionaryPatterns) - the basic patterns for XDI dictionary definitions
|
||||
> - [XDI Signatures](https://wiki.oasis-open.org/xdi/XdiSignature) - the pattern for digitally signing or encrypting an XDI graph, including an XDI message
|
||||
> - [XDI Link Contracts](https://wiki.oasis-open.org/xdi/LinkContractPattern) - how XDI does portable semantic authorization
|
||||
> - [XDI Policy Expression](https://wiki.oasis-open.org/xdi/XdiPolicyExpression) - how XDI does semantic policy expression
|
||||
> - [XDI Discovery](https://wiki.oasis-open.org/xdi/XdiDiscovery) - how XDI does P2P discovery of XDI endpoint URIs
|
||||
> - [Glossary](https://wiki.oasis-open.org/xdi/Glossary) - terminology used throughout the XDI 1.0 specifications
|
||||
> - [XDI Symbol Table](https://wiki.oasis-open.org/xdi/XdiSymbolTable) - summary of the symbols used in XDI syntax
|
||||
> - [XdiDollarDictionary](https://wiki.oasis-open.org/xdi/XdiDollarDictionary) - a list of all proposed entries for the XDI $ dictionary
|
||||
Informative Pages
|
||||
> - [Informative](https://wiki.oasis-open.org/xdi/CategoryInformative) (NOT part of XDI 1.0 specs)
|
||||
|
||||
## [XDI 1.0 Specs List](https://wiki.oasis-open.org/xdi/XdiOneSpecs) - a list of the proposed XDI 1.0 specifications
|
||||
|
||||
[**OASIS-XDI-Technical-Committee/xdi-spec-docbook/xdi**](https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/tree/master/xdi)
|
||||
|
||||
* [XDI Core V1.0](https://docs.oasis-open.org/xdi/xdi-core/v1.0/xdi-core-v1.0.html) Editors: Joseph Boyle; Markus Sabadello; Drummond Reed
|
||||
> The foundational spec on which all other specs depend. It defines the ABNF for the normative graph model, serialization formats, and addressing syntax.
|
||||
* [XDI Messaging V1.0](https://raw.githubusercontent.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/master/xdi/xdi-messaging-1.0/xdi-messaging-1.0-wd05.xml) Editors: Joseph Boyle; Markus Sabadello; Drummond Reed
|
||||
* [XDI Bindings V1.0](https://raw.githubusercontent.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/master/xdi/xdi-bindings-1.0/xdi-bindings-1.0-wd05.xml) Editors: Markus Sabadello; Drummond Reed; Joseph Boyle;
|
||||
> Defines the concrete binding of XDI messaging to specific transport protocols, beginning with the http/https protocol.
|
||||
* [XDI Link Contracts V1.0](https://raw.githubusercontent.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/master/xdi/xdi-link-contracts-1.0/xdi-link-contracts-1.0-wd03.xml) Editors: Dan Blum • Drummond Reed • Markus Sabadello
|
||||
> Defines the standard structure and vocabulary of XDI authorization statements, including XDI link contracts and policy expressions, so they are portable across all XDI endpoints.
|
||||
* [XDI Cryptography V1.0](https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/blob/master/xdi/xdi-cryptography-1.0/xdi-cryptography-1.0-wd02.xml) Editors: Markus Sabadello
|
||||
> Defines the semantics of using digital signatures and encryption with XDI graphs and XDI messages.
|
||||
* [XDI Discovery V1.0](https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/blob/master/xdi/xdi-discovery-1.0/xdi-discovery-1.0-wd01.xml) Editors: Joseph Boyle • Les Chasen • Markus Sabadello • Drummond Reed
|
||||
> Defines P2P discovery of XDI endpoint URI(s) given an XDI address (or a discoverable identifier that can be transformed into an XDI address).
|
||||
* [XDI Security Mechanisms V1.0](https://htmlpreview.github.io/?https://raw.githubusercontent.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/master/xdi/xdi-security-mechanisms-1.0/xdi-security-mechanisms-1.0-wd01.html) Editors: Joseph Boyle • Peter Davis • Dan Blum
|
||||
> Describes the mechanisms for implementing security in XDI, including transport-level security, message-level security, encryption, token formats, etc.
|
||||
* [XDI Privacy Mechanisms V1.0](https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/blob/master/xdi/xdi-privacy-mechanisms-1.0/xdi-privacy-mechanisms-1.0-wd01.xml) Editors: Dan Blum • Peter Davis • Drummond Reed
|
||||
> This working draft describes an environment for writing and publishing an OASIS specification using DocBook XML. It is an internal OASIS support document and not the basis of an OASIS specification in and of itself.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Loading…
Reference in New Issue