[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-08-22
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 22 August 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Drummond Reed
Les Chasen
Hubert Le Van Gong
Peter Davis
Eno Jackson
Dan Blum
Phil Windley
Andre Martins
Courtney Brown
Ning Zhang
Joseph Boyle
Markus Sabadello
Peter explained that there were only 3 issues remaining on the list of JIRA issues that need classification, and the SC members classified those this morning, so that task was finished.
The final issue touched on the need for an overview document that explains:
An introduction to XDI in general
A explanation of what spec covers what topic, and how they relate
Some examples (possibly a basic tutorial)
The suggestion was that we did need an overview document, but that we not write it until we have the other key specs that it serve as an overview of complete.
Drummond said he and Joseph plan to have another draft of XDI Core by next week if they make enough progress when they meet this coming weekend.
Last week, we began discussing the process of link contract instantiation. On Tuesday Aug 19 2014, a subset of the TC members had a dedicated call to explore this topic further. Among other new insights, the idea of a “community contract” was introduced, and the term “requestor contract” was suggested by Dan to replace the term “governor contract”.
Notes from that call can be found here:
https://www.oasis-open.org/committees/download.php/53921/LinkContractInstantiation17Aug2014.pdf
For reference, here is the link to Dan’s latest XDI Policy draft spec:
https://www.oasis-open.org/committees/download.php/53649/XDIPolicyDraft%20v6.docx
Since Markus was not able to attend the meeting, Drummond ran through the notes from the special meeting. The full transcript including discussion is below.
NOTE: THIS TRANSCRIPT CONTAINS ONE CHANGE THAT DRUMMOND REALIZED AFTER THE TC MEETING WAS OVER - SEE THE NOTE HIGHLIGHTED IN YELLOW
***************
Link Contract Instantiation Notes
AA = Authorizing Authority = the XDI authority authorizing a link contract granting permissions to an XDI graph.
RA = Requesting Authority = the XDI authority requesting a link contract to obtain permissions to an XDI graph.
CA = Community Authority = the XDI authority for a community contract.
Note: we need to be careful about using the acronyms AA, RA, and CA because they have specific meanings in other security/identity domains like SAML and PKI.
Link contract template. A link contract containing variables that defines the requirements for a link contract instance.
Link contract instance. A concrete link contract created from a link contract template.
Community contract. An AA link contract used to authorize a link contract instantiation request ({$do} message) from an RA.
Requestor contract (formerly “governor contract”). An RA link contract used to authorize a link contract instance write request ($set message) from an AA.
There are two special types of link contracts whose function is to control the writing of other link contracts into an authority’s graph.
This is new role for a link contract. A community contract does for an AA what a requestor contract does for an RA. A community contract allows the members of a community (of any size) to establish a common policy or set of policies that will govern members of the community accepting new link contracts from each other.
A simple community contract can prevent link contract requests from being used as a form of spam. The policy for this could be as simple as requiring a link contract request to come from another member of that community, and then enforcing this policy with a reputation system within the community.
A more sophisticated community contract could provide incentives for building trust within the community, for example by making it easier for community members with positive reputation to instantiate new relationships.
A community contract is not derived algorithmically from a link contract template address. Rather, it is simply a well-known XDI address to all members of that community.
A requestor contract is used by an RA to control authorization of link contract instances sent by an AA based on a specific link contract template. Since every AA must know the XDI address of the requestor contract that corresponds to a specific link contract template, the XDI address of a specific RA’s requestor contract is derived algorithmically from the XDI address of the link contract template.
Link contract instantiation MUST allow for:
Automated approval or denial of a link contract request by an AA (i.e., no user intervention required).
Manual approval or denial of a link contract request by an AA (i.e., user intervention required). Either an AA or an RA needs to be able to require an explicit approval or consent by the user. Note that this might require a decision on the link contract to be deferred. This may require additional messages to notify the RA that a request is pending, and that it ultimately approved or denied.
Delegated authority for approval. A typical use case would be parental approval, doctor/student, teacher/student.
Link contract instantiation also MUST allow for two types of initiation:
AA initiated. Example: user (as AA) clicks on an a XDI connect button on a web page or within an app.
RA initiated. Example: the XDI endpoint for a user’s friend (as RA) sends the user’s XDI endpoint an XDI contact request.
Link contract instantiation MUST allow for:
The AA to store a copy of the link contract instance.
The RA to store a copy of the link contract instance.
The AA selects one or more community contracts and writes them into its own XDI graph. Authorization: the AA’s own root link contract.
The RA selects a link contract template (or writes its own) and uses it to either:
Publish a link contract request message in an artifact such as a web link or a button (for an AA initiated link contract) or
Send a link contract request message directly to the XDI endpoint for an AA (for an RA initiated link contract).
The AA’s XDI endpoint either approves, denies or defers to the user or the user’s delegate the RA’s link contract request. Authorization: the community contract reference in the link contract request message.
Note that the deferred and delegated use cases may introduce additional approval steps here.
If approved, the AA writes the link contract instance to:
Its own XDI endpoint using its own root link contract. Authorization: the AA’s own root link contract.
If requested, to the RA’s XDI graph. Authorization: the RA’s requestor contract.
This example shows a two-part XDI message where part 1 (@0 in the message collection) requests link contract instantiation and part 2 (@1 in the message collection) requests some data permissioned by that new link contract. This illustrates how a single XDI messsage envelope could both request a new link contract and return data authorized by that contract.
=ra[$msg]@0/$is()/({$to})
=ra[$msg]@0$do/{$do}/(=ra)=ra#newsletter{$do}
=ra[$msg]@0<$sig>&/&/”...”
=ra[$msg]@0/$do/(=aa/+ca)+ca#community$do
=ra[$msg]@0/$is()/(=aa)
=ra[$msg]@0$do/{$do}/(=ra)=ra#newsletter{$do}
=ra[$msg]@0<$sig>&/&/”...”
=ra[$msg]@0/$do/(=aa/+ca)+ca#community$do
=ra[$msg]@1/$is()/({$to})
=ra[$msg]@1$do/$get/{$to}<#email>
=ra[$msg]@1<$sig>&/&/”...”
=ra[$msg]@1/$do/({$to}/(=ra)=ra#newsletter$do
Drummond noted that the (=ra) peer root at the start of the object (=ra)=ra#newsletter$do was not necessary because it would be resolved anyway, but that Markus wanted to include it to show that any peer root could be used.
We also discussed an example policy statement in community link contract that simply requires the requestor to be a member of that community.
(=aa/+ca)(+ca#community$do$if/$true)+ca/#member/{$from}
=aa[$msg]!:uuid:1234$do/$set/(=aa/=ra)=ra#newsletter$do
=aa[$msg]!:uuid:1234<$sig>&/&/”...”
=aa[$msg]!:uuid:1234/$do/(=ra/{from})=ra#newsletter$do
(=aa/=ra)=ra#newsletter$do/$get/=aa<#email>
NOTE: the link contract reference above was originally:
=aa[$msg]!:uuid:1234/$do/(=ra/=ra#newsletter{$do})$do
Drummond realized it would be both more consistent and more intuitive for the inner graph to represent the RA / AA relationship and for the requestor link contract name to match the link contract instance name, thus the change.
=ra[$msg]!:uuid:1234$/$is()/(=aa)
=ra[$msg]!:uuid:1234$do/$get/=aa<#email>
=ra[$msg]!:uuid:1234<$sig>&/&/”...”
=ra[$msg]!:uuid:1234/$do/(=aa/=ra)=ra#newsletter$do
(=aa/$public)$do/$get/=aa$public
**************
We have discussed the topic of transaction integrity a number of times in the past without reaching a conclusion. This seems to now have new relevance in conjunction with link contract instantiation.
The following document has a section titled “XDI Message Transactional Integrity Notes:
https://www.oasis-open.org/committees/download.php/53921/LinkContractInstantiation17Aug2014.pdf
A copy of these notes is also included below. We only had time for a very short discussion of this topic. The key points were:
TI is a highly complex topic.
Implementing TI can put a major burden on implementers.
Drummond felt we need to take some stance on TI in XDI Messaging V1, even if it is to declare that senders must do single operations in single XDI messages if they want to know whether they succeed or fail.
******************
Proposal: transactional integrity (TI) should be implemented through the requirement that all operations in a single atomic XDI message either MUST succeed or MUST fail.
Therefore, for a sender to control TI, he/she can divide a message into multiple messages and submessages as needed.
To ensure that each message succeeds or fails on its own, send each message separately:
To ensure that all 3 messages must succeed or fail as a package, send all 3 messages as a collection inside a single message:
=sender[$msg]!:uuid:123[$msg]!:uuid:111
=sender[$msg]!:uuid:123[$msg]!:uuid:222
=sender[$msg]!:uuid:123[$msg]!:uuid:333
To ensure that 2 messages succeed or fail as a package, but that the third can succeed or fail on its own:
=sender[$msg]!:uuid:123[$msg]!:uuid:111
=sender[$msg]!:uuid:123[$msg]!:uuid:222
=sender[$msg]!:uuid:456
******************
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]