Minutes: XRI TC Telecon 2-3PM PT Thursday 2010-02-04

[Drummond Reed <drummond.reed@xdi.org>]

Title: Federal Identity, Credentialing, and Access Management TFPAP, Version 1.0.1, September 4, 2009

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

Date:  Thursday, 04 February 2010 USA
Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

 

Will Norris

Breno de Medeiros

Markus Sabadello

John Bradley

Drummond Reed

Nat Sakimura

Scott Cantor

Nika Jones

 

 

1) XRD 1.0 URI COMPARISON ISSUE

 

Will is now enconsed in his new position and able to help with some editing again. He will get in touch with Eran and decide how to best integrate the changes indicated in the minutes of last week’s meeting.


2) XRD 1.0 WD 13 SIGNATURE ISSUE

See the thread Breno started here:

 

         http://lists.oasis-open.org/archives/xri/201002/msg00000.html

 

We agreed we need to decide this before the CD vote.

 

Breno acknowledged that this entire subject was discussed and decided about 6-9 months ago. The reason he raised it again was the concern that scripting languages do not have sufficient support for XML dSig, and therefore we may be looking at a real adoption issue. In addition, he felt that since that time, there have been two new developments. The first is the direction of OAuth. The tokens they are planning to support will use base64 encoding and not require canonicalization. PubSubHubbub is also concentrating on signed data.

 

Breno said the basic “simple sign” pattern first established in SAML requires base64 encoding of the payload, signing of this payload, sending both the signature and the encoded payload. The client can then verify the signature (or not) and unencode the payload.

 

Nat said that the implementation work for XRD, NRI did found that they were able to work around the XML dSig issues. The also tackled part of the problem by writing some of the libraries needed, such as for Ruby.

 

Breno explained that in AppEngine, much of the problem came from needing to parse X.509 certificates. But that’s not a problem directly with XML dSig.

 

He also explained that Salmon used the base64-encoding and signing approach because the protocol is optimized for signing. Because of this, it is relatively trivial to validate such signatures. That’s the tradeoff that the Salmon community made.

 

John pointed out that the certificate processing problems and the canonicalization/ signature processing problems are separate – the former do not go away even if we did base64 encoding.

 

Scott made the case that as a standard coming from a standards organization, there must be a good reason to use a signature method that is not a standard. Scott also believes that too many developers are trying to implement security in their apps, vs. using infrastructure to do that. This leads to all kinds of problems.

 

Scott also pointed out that XML dSig 2.0 should be out later this year and will be significantly simpler. But he believes that the majority of developers pushing back on XML dSig are actually pushing back on XML as a whole.

 

Will agreed, and mentioned that one of the goals of John (Panzer’s) work at Google has been to come up with a signature solution that works with both XML and JSON.

 

Breno also asked about whether we should have pursued enveloping signatures, vs. our current approach of enveloped signatures. This would produce a new document format, since it would have a different root element. This could be produced and verified easily, for example if it used the base64-encoding pattern.

 

There was an agreement that such a profile could be written as an adjunt to the current spec because it would produced a new document format (“signed XRD”).

 

Breno wants to think about it for a few days.

 

 

3) PROPOSAL FOR AN X.509-BASED XRI TRUST PROFILE

 

            http://lists.oasis-open.org/archives/xri/201001/msg00083.html

 

Breno has an idea for how to address some of the issues that came up on the last call where we discussed this. He has developed a decision tree about which inputs are trusted.

 

There is still an open issue about whether two or more XRDs can describe the same subject. Breno will send a proposal to the list to see if we can close on it via email; if not we will make this the primary subject of next week’s call so we can move on the CD 02 vote.

 

# ACTION: Breno to send a proposal to the list.

 

4) XRI 3.0 SYNTAX AND RESOLUTION

 

            http://www.oasis-open.org/committees/download.php/35972/xri-syntax-3.0-wd03.pdf

 

We did not have any time left to discuss this. Drummond warned that he may not be able to attend calls in the latter half of February due to being in a pressure cooker preparing for the RSA Conference the first week of March.


5) NEXT CALL

The next call is next week at the regular time.