xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Minutes: XDI TC Telecon Friday 2012-07-06
- From: Drummond Reed <drummond.reed@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Mon, 9 Jul 2012 00:29:45 -0700
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 06 July 2012 USA
Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING
Markus Sabadello
Mike Schwartz
Bill Barnhill
Giovanni Bartolomeo
Joseph Boyle
Drummond Reed
REGRETS
Phil Windley
THE ETHERPAD LINK FOR TODAY IS:
***** NEWS & UPDATES *****
--- LES CHASEN FROM NEUSTAR REJOINING THE TC
Drummond said Les on vacation this week but should be attending by next week.
--- DRUMMOND LONDON TRIP REPORT
Drummond noted two XDI items from his recent trip to London:
-
He gave an "Alice and Bob" tutorial on the XDI graph model at the Identity event on Monday June 11 that was very well received.
-
At the Technical track of the World Economic Forum Rethinking Personal Data meeting there was a very positive reception for using XDI link contracts to implement PDRL (Personal Data Rights Language).
--- CLOUD IDENTITY SUMMIT PREP
Mike, Drummond, and Phil are attending this event in Vail July 16-19. Mike plans to set up an XDI BOF at breakfast on Thursday morning.
***** PRESENTATIONS *****
--- MARKUS' PERSONAL DATA JOURNAL ARTICLE ON XDI
See Markus' message to the list at:
Markus has already received feedback from Mike, and Drummond plans to send some too. All TC members are invited to send feedback if they have any.
--- NEW XDI GRAPH PATTERNS DOC
Drummond noted that this doc has been revised to use a new diagram and improved terminology for multiplicity:
***** DECISION POINT QUEUE REVIEW *****
Drummond noted that there are at least three pressing isues in the queue (listed below). Drummond volunteered to create
--- MULTIPLICITY
Drummond and Markus have added improved terminology and detailed examples to this proposal.
--- IMPLICIT VS EXPLICIT CONTEXTS
Markus and Drummond are developing a proposal that they should have posted by early next week.
--- XDI AUTHENTICATION
See the following email discussion beginning with:
We did have time to begin discussion on this on the call -- see below.
***** DECISION POINTS FOR THIS CALL *****
Last week we decided the two top priority decisions for this call wpi;d be:
- Closing on the HTTP Message Binding.
-
Deciding about literal encoding in the JSON serialization.
--- HTTP MESSAGE BINDING
The proposal page is at:
Giovanni sent two messages to the list about this proposal:
Mike suggested that the current proposal be approved as it is and the issue of a full REST mapping should be treated separated from this proposal.
Giovanni asked why, when other data sharing work such as Linked Data and OData are focused on REST architecture, XDI is not similarly focused? He is concerned that the HTTP protocol already has the semantics needed for REST, so we should use it. It is very widely supported and it has a very robust infrastructure behind it.
Bill agrees with Giovanni's concerns, but is willing to support the current proposal as long as it is not the only HTTP binding the TC supports.
Mike pointed out that there is no REST binding of LDAP or SQL, whereas there are web services bindings, so he's not sure an HTTP REST binding for XDI is needed or will prove to be practical.
Giovanni countered with the example of Parlay, a telecom protocol, which was first bound to CORBA, which received only internal telecom use. The next binding was to web services, which also received limited use due to interoperability. Then they moved to a REST binding.
Drummond suggested that the current proposal takes the "simplest possible thing that could work" approach and does not preclude a REST binding.
Joseph suggested that the proposal be renamed to:
Simple HTTP Transport for XDI
There was more discussion about this. Finally Bill proposed that we divide the XDI-over-HTTP specs into two proposals
-
Simple HTTP Transport (a renaming of the current proposal)
This meets Bill's suggestions #1 and #3 on the Discussion page of the current proposal, and Bill agrees to the name change proposed here.
# BILL to rename or move the current page.
We then discussed the effort of moving forward a REST HTTP Binding. Giovanni asked how TC members would like to proceed.
# GIOVANNI will move forward with a proposal for a REST HTTP Binding.
We discussed the best way to advance discussion towards a proposal. The concensus was the following steps (which Drummond will note on the wiki):
-
Create a proposal page with the first part of the proposal for discussion.
- Start the discussion on the accompanying Discussion page.
-
Send an email to the list announcing Discussion on the Discussion page.
Bill pointed out that TC members can subscribe to wiki pages if they want to be notified about particular proposals and/or their Discussion pages.
--- XDI AUTHENTICATION
Since this was in active discussion on the email list, we decided to have a short discussion about it.
Bill explained his email in which he proposed that XDI authentication should use something like SASL.
He said SASL has been very effective, and we should emulate that success.
Mike pointed out that OpenID Connect also supports a multi-mechanism approach -- it allows different mechanisms including passwords. Bill said that he feels that is another reason to use a generic security framework specifically designed to support multiple bindings.
At this point Bill and Giovanni had to leave the call.
Mike then shared the view that we need to be more market-driven, i.e., take the 80/20 approach.
Drummond shared the view that he is relatively certain that what Respect Network will most likely need a p2p PKI authentication mechanism.
We discussed that perhaps a simpler approach than SASL would be to do specific authentication profiles. Each profile would need to define how to handle a message token, and also session management if appropriate.
At present, the potential authentication profiles would be:
Mike contributed the following example of what an OpenID Connect JWT web token looked like in OpenXDI today:
Sample XDI Message $token XDI statement:
@!4444$msg!0f9cfe5b-2f29-4a76-957c-fb61a6571a50/{JWT-0.6}$token!/(data:,eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvc2VlZC5nbHV1Lm9yZyIsInVzZXJfaWQiOiJAdGVzdDQiLCJhdWQiOiJAITExMTEhMDAwOCFBNjRDITQ3NUMiLCJleHAiOjEzNDE1OTc5NjcxNDMsIm94SW51bSI6IkAhNDQ0NCIsIm94VmFsaWRhdGlvblVSSSI6Imh0dHBzOlwvXC9zZWVkLmdsdXUub3JnXC9veGF1dGhcL3NlYW1cL3Jlc291cmNlXC9yZXN0djFcL294YXV0aFwvY2hlY2tfc2Vzc2lvbiIsIm94T3BlbklEQ29ubmVjdFZlcnNpb24iOiJvcGVuaWRjb25uZWN0LTEuMCJ9.676U8fktVJQyWOz9D79I72Li9EjNfaszlPF_4sxz6qs)
He then speculated what it might look like for a password token:
@!4444$msg!0f9cfe5b-2f29-4a76-957c-fb61a6571a50/{PASSWORD-0.6}$token!/(data:, xri:password)
Mike noted a concern about having a password authentication profile because it means the passwords will need to be stored on the XDI server.
That was as far as we took the discussion on this call.
--- JSON SERIALIZATION AND LITERAL ENCODING
In the time left, we had a brief discussiong about this decision. We have two competing proposals:
Mike agreed his proposal needs clarification:
The key contention between the two proposals is the format of literals in the JSON serialization.
-
Mike's proposal is that all literals use data: URI format.
- Drummond's proposal is that literals never use the data: URI format (with the exception of it that is the explicit datatype assigned to a literal, which would likelly be very rare, since there is no reason to use a data: URI if the necessary data encoding is already supplied by the serialization format).
The other place the propoals differ is in how the literal datatype metadata is provided.
It was agreed to make this the top priority decision point for the next call.
***** NEXT CALL *****
The next call is next week at the regular time.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]