OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16


Fulfilling my action items:

On 7/19/09 8:03 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:

> 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.

Backtracking is required here since multiple linked XRDs must be examined in
priority order, and each follows the same selection process.

> # ACTION: ERAN to post to the wiki/email the list with several options for
> how best to structure XRD links.

There is an interesting development in the Link spec that will probably
allow custom link extension to mandate a media type:

http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0159.html

If Link ends up going in that direction, I would suggest we simply define a
URI relation type (not register it as short name) under the XRD namespace
prefix that means Linked XRD. For parsing purposes, you look for a Link
element with this child Rel and use its URI(s). Any other Rel or MediaType
are ignored, while any URITemplate is left undefined.

I will let Will pick a relation type URI.
 
> 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.

So... I have a question to the security folks: since we don't really need a
Subject for host-meta, only a place to stick the trust subject, can we just
have a Subject-less document with an XRD-level <ds:KeyInfo>? But it does
require being able to put the hostname, port number, and protocol details
inside the ds:KeyInfo element which I am not sure is possible.

If not, my (super simple) proposal is:

<XRD>
    <SubjectPrefix>http://example.com/path</SubjectPrefix>

You can only have one of <subject> or <subjectPrefix> (or neither).
<SubjectPrefix> must be a valid, absolute URI. For trust purposes, it is
used exactly the same as Subject. It matches any URI with the same prefix,
following URI comparison rules (we need to find a good reference). No domain
wildcards allowed.

We can also turn this into an attribute of <Subject>, something like
'set="prefix"' which will allow other rules in the future (such as
'set="regex"').


> 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.

Will is back from vacation, still catching up.

> # ACTION: ERAN to determine if the XRI TC can provide any support for Mark's
> draft at IETF.

Mark indicated feedback is desired, as long as it is "short and sweet". If
you want to make a statement of support for making Link a Standards Track
RFC, please follow the instructions on the Last Call:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00844.html


EHL



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