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-10-04


XDI TC Minutes


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


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


ATTENDING

Les Chasen
Joseph Boyle
Animesh Chowdhury
Markus Sabadello
Phil Windley
Drummond Reed

GUESTS

Andy Dale (first half hour)

NEWS & UPDATES

Developer's Guide to XDI for Fall IIW 2013

Drummond said Steve Greenberg plans to have a version of the Developer's Guide to XDI ready for Internet Identity Workshop (Oct 22-24 in Mountain View).


PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

No progress to report on XDI Core and XDI Messaging this week.


Canonicalization

Joseph noted that the JSON community is still working on the issue of defining a canonical form of JSON. This is important to us for XDI Signatures. However we didn’t have time to go into this in any detail. Joseph and Drummond will discuss it before the next call and put in on that agenda.


XDI Message Signing and Key Pairs

Drummond, Markus, and Dan did work this week along with Andy Dale of Respect Network on how key pairs for message signing and encryption should be represented in the graph. Following is an example of a proposed singleton pattern:


$msg$sig$keypair$public<$key>&/&/”...”

$msg$sig$keypair$private<$key>&/&/”...”

$msg$sig$keypair$not$valid$before<$t>&/&/”...”

$msg$sig$keypair$not$valid$after<$t>&/&/”...”

$msg$sig$keypair/$is+/$rsa$2048


The collection version of this pattern would be:


$msg$sig[$keypair]!:uuid:1$public<$key>&/&/”...”

$msg$sig[$keypair]!:uuid:1$private<$key>&/&/”...”

$msg$sig[$keypair]!:uuid:1$not$valid$before<$t>&/&/”...”

$msg$sig[$keypair]!:uuid:1$not$valid$after<$t>&/&/”...”

$msg$sig[$keypair]!:uuid:1/$is+/$rsa$2048


With regard to the specific $words used, Markus suggested that we look at the existing Policy _expression_ vocabulary for potential reuse before adding these new $words.

Andy asked about certs, which typically contain many more items of metadata describing a keypair (and specifically the public key in the keypair). Specifically:

  1. Will the TC define all the elements of an X.509 cert?

  2. Should we define an XDI context for X.509 certs?

  3. Should an XDI endpoint be able to dynamically create an X.509 cert?

Animesh said that he thought we should support X.509 certs because they are so widely used.

Andy asked if we should “explode” the X.509 cert into individual attributes in the graph or just store it as a blob.

There was a consensus that an XDI server should be able to dynamically generate an X.509 cert if the server has access to the private key needed to sign the cert.

Drummond supported X.509 compatability, but felt that we should still evolve one or more “native” XDI keypair metadata elements.

Andy said that he would like to avoid the problem of the SAML Metadata spec, which was needing to manage cert metadata both within the cert and also outside the cert.

Specifically, Andy’s suggestion would work this way:

  1. To be X.509 compatible, each keypair MUST include the XDI attribute statements needed for an X.509 cert, and optionally other statements.

  2. We specify a way to EITHER:

    1. Dynamically generate the X.509 cert from that metadata.

    2. Store and serve a blob based on that metadata.

Les thought it would be less latency for the server to store the blob, but agreed with Andy that it would be more efficient for an XDI server (or a related component) to verify date validity by checking the date attribute.

Animesh pointed out that it can be complex to compose a particular X.509 cert.

Drummond pointed out the issue that an XDI server can only generated a cert that is signed by the authority for that server, i.e., that has access to its private key.

We agreed that the next step is to run this issue by Peter and Dan to get their input.

The Top-Level Collection Pattern Question

Drummond introduced a new topic triggered by the keypair metadata examples above. Specifically, it is two questions about best practices:

  1. Should collections of uniquely identified attributes at the top level of the graph vs. under a specific authority node?

  2. If so, should this apply only to collections containing UUIDs or other globally unique collection member identifiers, or can it appy more broadly?


For example, look at the following options:


1) A FULLY CONTEXTUAL COLLECTION PATTERN


[=]!:uuid:3$msg$sig[$keypair]!:uuid:1$public<$key>&/&/”...”

[=]!:uuid:3$msg$sig[$keypair]!:uuid:1$private<$key>&/&/”...”

[=]!:uuid:3$msg$sig[$keypair]!:uuid:1$not$valid$before<$t>&/&/”.”

[=]!:uuid:3$sig[$keypair]!:uuid:1$not$valid$after<$t>&/&/”...”

[=]!:uuid:3$sig[$keypair]!:uuid:1/$is+/$rsa$2048


2) A PARTIALLY CONTEXTUAL COLLECTION PATTERN


$msg$sig[$keypair]!:uuid:1$public<$key>&/&/”...”

$msg$sig[$keypair]!:uuid:1$private<$key>&/&/”...”

$msg$sig[$keypair]!:uuid:1$not$valid$before<$t>&/&/”...”

$msg$sig[$keypair]!:uuid:1$not$valid$after<$t>&/&/”...”

$msg$sig[$keypair]!:uuid:1/$is+/$rsa$2048


3) A FLAT TOP-LEVEL COLLECTION PATTERN


[$keypair]!:uuid:1$public<$key>&/&/”...”

[$keypair]!:uuid:1$private<$key>&/&/”...”

[$keypair]!:uuid:1$not$valid$before<$t>&/&/”...”

[$keypair]!:uuid:1$not$valid$after<$t>&/&/”...”

[$keypair]!:uuid:1/$is+/$rsa$2048


Note that in this pattern, the members of this collection would be referenced from other  external contexts. For example:

$msg$sig$keypair$public$key/$ref/[$keypair]!:uuid:1$public<$key>

$msg$encrypt$keypair$public$key/$ref/[$keypair]!:uuid:2$public<$key>


$msg$sig$rsa$256$keypair$public$key/$ref/

[$keypair]!:uuid:1$public<$key>

$msg$rsa$256$encrypt$keypair$public$key/$ref/

[$keypair]!:uuid:2$public<$key>


$msg$sig[$keypair]!:uuid15$public$key/$ref/

[$keypair]!:uuid:1$public<$key>

$msg$encrypt[$keypair]!:uuid16$public$key/$ref/

[$keypair]!:uuid:2$public<$key>


Markus explained his original input to Andy that a keypair describes an XDI endpoint itself and not a person, and thus should be an attribute of the graph and not of a particular person.


Phil asked about a person having multiple graphs with multiple endpoints, pointing out tha this is essentially how an individual can act as their own CA.  Drummond agreed with Phil that this shows even more why a keypair should be an attribute of an XDI graph and not a person or organization.


Returning to the “top-level pattern” question, Animesh said he would choose pattern #3 because the structure is simpler and the address is shorter.


Markus said he would prefer #2 because you have separate collections for signing keypairs and encrypting keypairs (which you don’t have in #3).


Drummond pointed out that different types of keypairs needed (signing, encryption, certificate, etc.) could all references into a top-level collection just like we have been proposing for referencing common contact attributes from different contact cards (personal, work, sports, etc.)  For example, here is how different types of phone numbers can reference into a single telephone number collection:


=markus/$ref/[=]!:uuid:3

[=]!:uuid:3[<+tel>]<!:uuid:21>&/&/”...”

[=]!:uuid:3[<+tel>]<!:uuid:22>&/&/”...”

[=]!:uuid:3[<+tel>]<!:uuid:23>&/&/”...”

[=]!:uuid:3[<+tel>]<!:uuid:24>&/&/”...”


[=]!:uuid:3<+tel>/$ref/

[=]!:uuid:3[<+tel>]<!:uuid:21>

[=]!:uuid:3+work[<+tel>]#0/$ref/

[=]!:uuid:3[<+tel>]<!:uuid:22>

[=]!:uuid:3+work[<+tel>]#1/$ref/

[=]!:uuid:3[<+tel>]<!:uuid:22>

[=]!:uuid:3+home<+tel>/$ref/

[=]!:uuid:3[<+tel>]<!:uuid:21>

[=]!:uuid:3+home+fax<+tel>/$ref/

[=]!:uuid:3[<+tel>]<!:uuid:24>


Note, however, that in this example the [<+tel>] collection appears under [=]!:uuid:3 because a telephone number is an attribute of a person, not of an XDI graph.

We then discussed what is the natural level at which collections of entities or attributes should appear. Drummond pointed out the top-level name/number reference pattern as the origin for this discussion:


=markus/$ref/[=]!:uuid:5

=drummond/$ref/[=]!:uuid:6

[=]!:uuid:5/+friend/[=]!:uuid:6


In this pattern, the singletons =markus and =drummond reference UUIDs that are members of the top-level collection of people. So they can be referenced within this top-level collection by any other context that needs them.

Markus pointed out that this works well for top-level entity collections, but it only works for top-level attribute collections if they describe the outer root context, i.e., the local XDI graph.

There was consensus that collections of entities or attributes that describe a person should be put directly under the person’s context node, not the outer root node.

When a person has multiple local graphs or subgraphs representing different pseudonyms or personas, they can share attributes by referencing back into collections under a primary persona.

Effects on XDI Messaging and XDI Signatures

We did not have time to discuss how the discussion on XDI Message Signing and Key Pairs above should affect the XDI Messaging and XDI Signature specs. Drummond suggested these next steps:

  1. We need to add the $keypair vocabulary to the XDI Signatures wiki page.

  2. We need to make any adjustments to the XDI Messaging template to include additional requirements of public key discovery.

  3. We need to make sure that the public link contract allows access to the public key.

  4. If needed, add key pair attribute and cert vocabulary to Policy _expression_ wiki spec page.

#MARKUS AND DRUMMOND will work on these steps.


DECISION POINTS FOR THIS CALL

Dictionary Syntax

We did not have time to discuss on this call—it will be added to next week’s agenda.



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

The next call is next week at the regular time.




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