OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes: XDI TC Telecon Friday 2013-08-09


XDI TC Minutes


Following are the minutes of the unofficial telecon of the XDI TC at:


Date:  Friday, 09 August 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


ATTENDING

Markus Sabadello

Joseph Boyle

Animesh Chowdhury

Les Chasen

Drummond Reed

Dan Blum

GUESTS

Andy Dale (start of the meeting)

Steve Greenberg (end of the meeting)


PRESENTATIONS/DISCUSSIONS

Proposed Initial Schedule for Working Draft Specs

Andy Dale, Respect Network VP Development, attended the first part of the meeting to propose a timeline for our Core and Messaging specs based on the requirements of the Respect Network Founding Partners. The next major milestone is Internet Identity Workshop (Oct 22-24 in Mountain View), by which time Respect Network would like to publish its proposed XDI APIs, which would mean we need solid Working Drafts by mid-Sept.


Drummond suggested that we decide about issues management using our wiki or Jira.

# DRUMMOND to talk with Markus and post a proposal for issues management.

XDI2 JSON Native Values

Markus provided an update on work he has been doing to implement native JSON values in XDI2. He said that although it was conceptually a small change to the spec for XDI serialization that the objects of XDI statements could be all JSON data types, it actually affecte many parts of the XDI2 code base.


It is now implemented; you can send numbers and booleans as native JSON data types. Joseph asked if this provides “round-tripability” for storage, i.e., if you $set a string, you will $get a string; if you $set a number, you will $get a number. Markus confirmed that this was the case.


This led to a discussion about the null value issue, i.e., how to represent an XDI attribute whose value is null. Markus explained his understanding of how this currently works by the absence of a value context node, and thus why JSON null values were not supported. Joseph was uncomfortable that JSON null values were not explicitly supported. We discussed but did not decide about this issue.


# DRUMMOND to propose a wiki page on this issue.

Attribute Syntax Question

Drummond displayed an example reflecting a syntax question he has had in preparing graph models for the Core spec. The question is whether all attributes should be in chevrons, including nodes representing instances of an attribute class.

# DRUMMOND will send this proposal to the list.

Link Contract Initiation Patterns

On last week’s call we had an excellent discussion of the use cases and protocol flows for creating relationships between XDI authorities that result in either one-way or bilateral link contracts. Animesh and Drummond took action items to prepare proposed sequence diagrams. The two flows they agreed to diagram are:


  1. Alice->Acme. This is a person-to-business flow in which Alice visits a web page from Acme containing a Connect button that Acme has place there to offer to form a connection (XDI link contract) with a visitor like Alice. (Note that in Drummond’s flow, this Connect button is explicitly scoped for Alice just to provide an email address.)

  2. Alice->Bob. This is a person-to-person flow in which Alice visits a web page from Bob (a “cloud page”) containing a Connect button that Bob has place there to offer to form a connection with a visitor like Alice.


Following are Animesh’s two flow diagrams.

Alice->Acme (Animesh version)



Alice->Bob  (Animesh version)



We began by reviewing Animesh’s Alice->Acme diagram. We discussed the following points about this flow:


We next went over Drummond’s Alice->Acme flow.

Alice->Acme (Drummond version)



Alice->Bob (Drummond version)



Following is the text to generate Drummond’s diagram’s at http://websequencediagrams.com:


Alice->Acme Text

participant Alice

participant "Alice\nCSP" as AliceCSP

participant "Alice\nXDI Server" as AliceXDI

participant "Connect\nService" as Connect

participant "Discovery\nService" as Disco

participant "Acme\nXDI Server" as AcmeXDI

participant "Acme\nWebsite" as Acme



note left of "Alice": Alice has discovered Acme's web form

Alice->Acme: Get web form with Connect button

Acme-->Alice: Return web form

Alice->Alice: Click Connect button

Alice->Connect: Submit connect request

note right of Connect: Only if not logged in

Connect-->Alice: Return Connect form

Alice->Alice: Enter XDI address

Alice->Connect: Return Connect form

Connect->Disco: Discover Alice CSP endpoint

Disco->Connect: Return Alice CSP endpoint

Connect-->Alice: Redirect to CSP endpoint

Alice->AliceCSP: Submit connect request

note right of AliceCSP: Only if not logged in

AliceCSP-->Alice: AuthN challenge

Alice->AliceCSP: AuthN response

AliceCSP->AliceXDI: Submit XDI request

AliceXDI->AliceXDI: Process XDI request (run rules)

AliceXDI-->AliceCSP: Return XDI response

AliceCSP->AliceCSP: Process XDI response (generate form)

AliceCSP-->Alice: Return confirmation form

Alice->Alice: Select data & confirm link contract

Alice->AliceCSP: Submit confirmation form

AliceCSP->AliceXDI: $set Acme link contract

AliceXDI->Disco: Discover Acme XDI endpoint

Disco-->AliceXDI: Return Acme XDI endpoint

AliceXDI->AcmeXDI: $set Acme link contract

AcmeXDI-->AliceXDI: OK

AliceXDI-->AliceCSP: OK

AliceCSP-->Alice: Redirect to success page

Alice->Acme: Get success page

Acme-->Alice: Return success page


Alice-Bob Text

participant Alice

participant "Alice\nCSP" as AliceCSP

participant "Alice\nXDI Server" as AliceXDI

participant "Connect\nService" as Connect

participant "Discovery\nService" as Disco

participant "Bob\nXDI Server" as BobXDI

participant "Bob\nCSP" as BobCSP

participant Bob


note left of "Alice": Alice has discovered Bob's cloud page

Alice->BobCSP: Get cloud page with Connect button

BobCSP-->Alice: Return cloud page

Alice->Alice: Click Connect button

Alice->Connect: Submit connect request

note right of Connect: Only if not logged in

Connect-->Alice: Return Connect form

Alice->Alice: Enter XDI address

Alice->Connect: Return Connect form

Connect->Disco: Discover Alice CSP endpoint

Disco->Connect: Return Alice CSP endpoint

Connect-->Alice: Redirect to CSP endpoint

Alice->AliceCSP: Submit connect request

note right of AliceCSP: Only if not logged in

AliceCSP-->Alice: AuthN challenge

Alice->AliceCSP: AuthN response

AliceCSP->AliceXDI: Submit XDI request

AliceXDI->AliceXDI: Process XDI request (run rules)

AliceXDI-->AliceCSP: Return XDI response

AliceCSP->AliceCSP: Process XDI response (generate form)

AliceCSP-->Alice: Return confirmation form

Alice->Alice: Select contact card(s)

Alice->AliceCSP: Submit confirmation form

AliceCSP->AliceXDI: $set Acme link contract

AliceXDI->Disco: Discover Acme XDI endpoint

Disco-->AliceXDI: Return Acme XDI endpoint

AliceXDI->BobXDI: $set Acme link contract

BobXDI-->AliceXDI: Success

AliceXDI-->AliceCSP: Success

AliceCSP-->Alice: Redirect to connected cloud page

Alice->BobCSP: Get connected cloud page

BobCSP-->Alice: Return connected cloud page

note right of BobCSP: Asynchronous

BobCSP->Bob: You have new connection with Alice; select contact card(s)

Bob-->BobCSP: Submit selection

BobCSP->BobXDI: $set link contract

BobXDI->Disco: Discover Alice CSP endpoint

Disco-->BobXDI: Return Alice CSP endpoint

BobXDI->AliceXDI: $set link contract

AliceXDI-->BobXDI: OK

BobXDI-->BobCSP: OK

BobCSP-->Bob: OK


The key differences in Drummond’s flows were that:

  1. An intermediate Connect service is used so that Alice can save state for connecting to her preferred XDI service provider.

  2. Alice only deals with her own CSP (Cloud Service Provider), never Acme’s CSP.

  3. Alice’s XDI server saves a copy of the link contract that Alice has approved with Acme, and then Alice’s XDI server saves an exact copy of that contract to Acme’s XDI server.

At that point we ran out of time. We agreed to continue advancing discussion of these sequence diagrams offine or over the list in the following week, and continue the discussion on next week’s telecon.

At the end of the meeting, Steve recommended a free open source UML diagramming tool, coming out of the Apache Project, called PlantUML.


DECISION POINTS FOR THIS CALL


None scheduled.



DECISION POINT QUEUE REVIEW

The decision queue stack is shown on the following three auto-generated Category pages:


  https://wiki.oasis-open.org/xdi/CategoryLastCall

  https://wiki.oasis-open.org/xdi/CategoryCurrent

  https://wiki.oasis-open.org/xdi/CategoryHighPriority


See also this list of proposals that need to be developed:


  https://wiki.oasis-open.org/xdi/XdiPendingIssues


NEXT CALL

Next week at the regular time.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]