[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-08-09
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)
Markus Sabadello
Joseph Boyle
Animesh Chowdhury
Les Chasen
Drummond Reed
Dan Blum
Andy Dale (start of the meeting)
Steve Greenberg (end of the meeting)
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.
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.
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.
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:
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.)
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.
We began by reviewing Animesh’s Alice->Acme diagram. We discussed the following points about this flow:
Alice must enter her own XDI address (“cloud name”).
Alice is always dealing with Acme’s CSP, which has security implications.
The flow assumes that Alice interacts with her IDP. Dan pointed out that privacy would be increased if Alice’s pcloud could serve in that role. This is the option that was discussed in the meeting with Eve Maler and the UMA group at the Cloud Identity Summit.
Dan had questions about the token expiration and inactivation to prevent token replay attacks.
We next went over Drummond’s Alice->Acme flow.
Alice->Bob (Drummond version)
Following is the text to generate Drummond’s diagram’s at http://websequencediagrams.com:
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
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:
An intermediate Connect service is used so that Alice can save state for connecting to her preferred XDI service provider.
Alice only deals with her own CSP (Cloud Service Provider), never Acme’s CSP.
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.
None scheduled.
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 week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]