Re: [xdi] XDI TC Notes Unofficial Telecon Monday 2016-01-04

Good point, Markus. I agree $digest should be in the Crypto spec.

On Mon, Jan 4, 2016 at 4:41 PM, Markus Sabadello <> wrote:

  
    
  
  

    
Quick comment about the following
      sentence from the notes:

      "This uses the $digest keyword, which Markus will add to the
        Messaging spec."

        

        I believe the $digest keyword will be defined in Cryptographic
        profiles or Security Mechanisms, rather than in Messaging.

        

        The Link Contracts spec can then give an example how a link
        contract can use the $digest keyword in a policy.

        

        Markus

      

      On 01/04/2016 08:16 PM, Markus Sabadello wrote:

    

    
      
      

        XDI
            TC Notes
        

        
Following are the notes of the unofficial
            telecon of the XDI TC held on:

        
Date: Monday, 4 January 2016 USA

          Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30
            UTC)

        

        
The TC operates under a
              standing rule approved 17 July 2008 under
            which the TC does not hold regular official meetings and
            conducts all business by electronic ballot only. Unofficial
            weekly meetings are held to enable discussion among members
            but no business is conducted nor actions taken.

        ATTENDING
        
Drummond Reed

          Les Chasen

          Markus Sabadello

          Joseph Boyle

        REGRETS
        

        Update on Publishing XDI Core 1.0 Committee
            Specification Draft 01
        
Drummond gave a brief report on progress.

        
https://lists.oasis-open.org/archives/xdi/201511/msg00011.html

        

        
Chet and Ken Holman from the OASIS DocBook TC
            got back to Joseph and Drummond with answers to most of our
            questions. That leaves two final tasks:

        

        
# ACTION ITEM: JOSEPH AND DRUMMOND to do a
            final joint editing session.

        

        
# ACTION ITEM: DRUMMOND to add a wiki page
            with any proposed revisions for future versions of XDI Core
            1.0.

        XDI Agent Demo
        
Markus gave another demo of new functionality
            he has developed for an XDI agent (a Java desktop app) that
            can connect to XDI endpoints:

        
https://github.com/projectdanube/XDINinja-swing

        

        
In this demo, he showed an “automatic”
            connection invitation. In this scenario, Alice sends a
            connection invitation to Bob, and when Bob accepts, the
            connection request from Bob back to Alice is automatically
            accepted by Alice.

        

        
To do this, the link contract policy
            specifies that it will accept an XDI message with a specific
            digest hash value. This uses the $digest keyword, which
            Markus will add to the Messaging spec.

        

        
The other new functionality is an XDI chat
            functionality. Markus has implemented this with two link
            contracts, one in both directions, between Alice and Bob.
            These link contracts are in fact quite similar to the ones
            for reading and writing profile data that Markus showed last
            week. 

        

        
He showed basic chat messaging between Alice
            and Bob. These messages are not encrypted but they both have
            signatures—one from the sender (applied by the agent) to
            verify the message at Alice’s endpoint, and then one applied
            by Alice’s endpoint to send to Bob’s endpoint.

        

        
Markus explained that the addition of
            signatures and encryption, and the removal of signatures and
            encryption, are all controlled either by parameters on a
            message or server configuration. However the basic sequence
            of operations is the same, and this is what is documented in
            Markus’ earlier flow diagrams and in the Messaging spec.
            Markus felt that some sequence diagrams will be needed in
            the Messaging spec.

        Queues, Conversations, Channels, and Group
            Messaging
        
Drummond brought up the idea of messaging
            queues and conversations as a design approach that enables a
            single link contract to control access to the queue. This
            took us into a whole set of topics around design patterns
            for direct and group messaging.

        

        
Markus took the following group notes about
            this conversation:

        

        
A queue has a UUID [$queue]*!:uuid:ex-1

        
   A queue contains a set of conversations

        

        
Conversations have UUIDs

        
   [$conversation]*!:uuid:ex-2
            and [$conversation]*!:uuid:ex-3

        

        
# ACTION ITEM: ALL think about $ dictionary
            word for conversations that is shorter than “$conversation”.

        

        
A conversation is a sequence of messages.

        

        
Alice and bob want link contract to share a
            queue that allows both to read/write messages and
            conversations.

        

        
Current "bi-directional link contract
            pattern" used in XDI Ninja demo app for chat:

        

        

            (=alice/=bob)$do/$set/=alice#chat$channel[$msg]

        
 (=alice/=bob)$do$if/...

        

        

            (=bob/=alice)$do/$set/=bob#chat$channel[$msg]

        
 (=bob/=alice)$do$if/...

        

        
Closed "centrally controlled" channel:

        

        

            (=alice/+group)$do/$set/=alice#chat$channel[$msg]

        

            (=alice/+group)($do$if/$true)+group/$has/{$from}

        
 +group/$has/=bob

        
 +group/$has/=charlie

        

        
  -> =alice controls list of group members

        
  -> all message are sent via =alice
            (centralized, hub-and-spoke channel)

        
  -> group/channel lifecycle is controlled
            by =alice

        

        
Proposed shared queue context link contract
            pattern:

        

        
 (=alice)+group/$has/=alice

        
 (=alice)+group/$has/=bob

        
 (=alice)+group/$has/=charlie

        

        
 (=bob)+group/$has/=alice

        
 (=bob)+group/$has/=bob

        
 (=bob)+group/$has/=charlie

        

        
 (=charlie)+group/$has/=alice

        
 (=charlie)+group/$has/=bob

        
 (=charlie)+group/$has/=charlie

        

        
  -> group continues to exist as long as
            it still has at least 1 member

        
  -> new members joining requires / does
            not require invitation from existing member (depends on
            policy)

        NEXT REGULAR CALL
        
The next call will be the following week at
            the usual time (Monday 10AM PT). The link to where agenda
            items can be posted for the next meeting is:
            https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing