[mdx] new document: SAML Profile for the Metadata Query Protocol

[Ian Young]

Carrying on the thread about the second, layered, document.

On 25 Oct 2013, at 02:21, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 10/17/13, 10:56 AM, "Ian Young" <ian at iay.org.uk> wrote:
>> 
>> * I've made it clear that this is a profile restricted to SAML entities
>> using SAML metadata. If there is a need for other related profiles in the
>> distant future (SAML entities using non-SAML metadata, non-SAML entities
>> using SAML metadata) then we can write new profiles when we need them.
> 
> After a detailed read, I'm still not sure I see a good reason to constrain
> this to SAML entities. The only thing really specific to SAML is the
> artifact/SHA-1 part, but that doesn't seem like a dominant portion. It
> could maybe be moved into a subsection or toward the end if that helps
> de-emphasize it.

You and Leif appear to agree on this, and I haven't heard anything in the other direction. I'll revise accordingly:

Abstract and introduction:

   This document profiles the Metadata Query Protocol
   [I-D.young-md-query] for use with SAML metadata [SAML2Meta].

Drop the scoping section in the introduction, which was:

   The following use cases are not in scope for this profile:

   o  The use of SAML metadata by entities other than SAML entities.

   o  The use of metadata other than SAML metadata by SAML entities.

I think we can let everything else stand, unless someone feels strongly that we need to move the SHA-1 stuff to some kind of SAML protocol specific appendix.

Text prior to the above changes can be reviewed here:

https://github.com/iay/md-query/blob/master/draft-young-md-query-saml.xml



>> * The Security Considerations is now much more specific about the
>> integrity mechanism to use. I think there probably ought to be a
>> reference to SAML2MetaIOP as part of that; suggestions welcome as to
>> exactly how to phrase that.
> 
> I don't know, I'm not sure it adds anything really. IOP is pretty
> specifically vague about distribution, so it seems orthogonal to this (in
> that they compose naturally but without imposing constraints on each
> other, really). What were you thinking the reference would serve?

I was thinking that we could use something to indicate that the returned document should stand alone, and that any TLS involved to the query endpoint should not be factored in to runtime trust. I had been remembering that as part of the IOP, but I guess I must have misremembered as I don't see it in there now that I come to look again. Neither does it appear to be in the InCommon implementation profile, which was the next place I looked.

Does this ring a bell for anyone? If so, which reference am I thinking of?

I guess another question would be whether we do actually need such a reference, or would prefer to be silent on that issue.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20131125/70c00c7f/smime.p7s>