I assume that the "ds:KeyInfo at the XRD level" idea will be the mechanism of choice for XRI-based applications such as XDI messaging.
I.e. when =markus sends a signed XDI message to =drummond, the signature can be verified by discovering =markus' key from his XRD.
From an XRI perspective I think it makes total sense to have the "key info of the XRD Subject" at the XRD level.
Markus
On Mon, Jul 20, 2009 at 5:03 AM, Drummond Reed <> wrote:
Following are the minutes of the unofficial telecon of the XRI TC at:
Date: Thursday, 16 July 2009 USA
Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)
ATTENDING
Eran Hammer-Lahav
Scott Cantor
Nika Jones
Joseph Holsten
Breno de Medeiros
John Bradley
Nat Sakimura
George Fletcher
Drummond Reed
REGRETS
Will Norris (on vacation)
1) XRD 1.0 - LINK PROCESSING RULES
See this thread:
http://lists.oasis-open.org/archives/xri/200907/msg00075.html
Eran's proposal is "best match", i.e.:
* Once an XRD is retrieved, the processor looks for a link match.
* If it finds exactly one, it is done.
* If it finds more than one, it selects based on priority (identical
priority = random selection)
* If it finds none, it looks for linked XRDs.
* It it finds exactly one, it follows it.
* If it finds more than one, it selects based on priority (identical
priority = random selection)
We didn't discuss backtracking in the case of multiple XRD links. This is
still an open issue.
We discussed that if XRD link behavior is application specific, that makes
it hard/impossible to develop a generic XRD library. So standardizing XRD
linking has real advantages.
We discussed using a dedicated XRD element for linked XRDs vs. a regular
link. The consensus was that XRD links needed all the same processing as
regular links, so we should just use a link.
# ACTION: ERAN to post to the wiki/email the list with several options for
how best to structure XRD links.
2) XRD 1.0 KEY MANAGEMENT
The next topic was key management and how ds:KeyInfo was going to be used,
as discussed by Scott and Nat on the list.
Scott clarified this by saying there are three places ds:KeyInfo can appear:
1) Inside a signature.
2) Inside a link.
3) At the XRD level.
The first two uses are clear: when ds:KeyInfo is inside a signature, it is
the key info for the signer. When inside a link, it is key info for the
signer of the target XRD.
The third case is new. There was concensus that ds:KeyInfo at the XRD level
should represent the key info of the XRD Subject, even if the subject is not
the signer of the XRD.
Scott also explained that SAML found that in some cases ds:KeyInfo was not
enough, and that it needed to be wrapped in another element.
John said that a rising requirement is the need to transition from XRD
discovery/trust to SAML metadata discovery/trust.
Breno said that there are two trust phases: a boostrapping phase, and a
chaining phase. XRD must define the XRD bootstrapping phase, and then the
XRD chaining phase, but could transition over into other signing protocols
such as PKIX.
Scott said that we should not duplicate what PKIX does.
# ACTION: Scott to send a proposal to the list on what should be included in
the XRD trust section.
3) LRDD - SUBJECT OF A HOST-META XRD
See:
http://lists.oasis-open.org/archives/xri/200907/msg00007.html
Eran said he had not heard any opinions back about this. The consensus on
the call was to just go with Eran's proposal for describing a "SubjectSet"
with a very simple XML structure, and to NOT make it extensible.
We then discussed if this should be defined in LRDD or XRD. The consensus
was XRD.
# ACTION: ERAN to proceed with a writeup of the proposed SubjectSet element.
4) XRD 1.0 SPEC STATUS/IMPLEMENTATIONS
Joesph asked how close we were. Eran said the XRD 1.0 schema is done, and we
just need to decide about the trust section, and the remaining open issues
on LRDD. Eran also said Mark Nottingham has just posted his Link Header spec
(revision 06) for IETF last call. This is our last dependency.
# ACTION: ERAN and WILL to coordinate on the next draft.
# ACTION: ERAN to determine if the XRI TC can provide any support for Mark's
draft at IETF.
5) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES
No change since the last report: Drummond is making progress but will not
have this ready until early August due to travel/vacation time.
6) NEXT CALL
Next week, standard time. Note: Drummond will be on vacation next week so he
will not be able to attend; someone else will need to send an agenda and
take notes.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
