Per-Entity Metadata Working Group

[Scott Koranda <>]

Hi Chris,

> I read the notes on the wiki and the google doc and couldn't find this
> requirement anywhere.

It is not a requirement.

As I understand it is a long standing discussion ongoing
within InCommon.

> If I were to fall back on something it would be the list of supported
> software tools/platforms that a federation operator has.
> This appears hard to come by, but I do see this:
> https://spaces.internet2.edu/display/InCFederation/Software+Guidelines
> 
> And this: 
> https://spaces.internet2.edu/display/InCFederation/Using+Other+Software#Usi
> ngOtherSoftware-using-ad-fs
> 
> This is much like what CAF has for statements around software -- we
> support the protocol not necessarily specific instances of software for
> configurations.  
> It allows a demarcation to be made by the fedop, but in practice
> sites/implementors want to know what to do with a given piece of software.
> 
> In this case with ADFS and this working group, I think it would be prudent
> to link to inCommon's supported software(protocols) and if ADFS isn't
> there, then THAT's a conversation to have as opposed to 'should MDQ use
> TLS transport to convey trust'.  It doesn't feel like this aspect is in
> the right place. 

The question is not 'should MDQ use TLS transport to convey
trust?'

The question is 'should planning and a roadmap for an InCommon
operated MDQ service include using TLS transport to convey
trust?'

I understand your statement above, but I want to explore the
question (see the other thread I have started) in this working
group, for at least a little while.

It should not distract from other progress, but I want the
discussion to inform us and the roadmap.

> I definitely want to see better ADFS integration for federations in
> general though.  It seems to be coming in MSFT Server2016TP3 (is that out
> yet?) that can ingest an aggregate. That said, I have yet to see it in
> action.  What happens in practice for any ADFS install is a ton of
> powershell bulk loading things and applying settings to do anything --
> even with MDQ.  

For consuming the full aggregate, yes.

Some InCommon Participants, however, want to leverage HTTPS
for consuming specific entity metadata with ADFS.

It is not an ideal federation integration pattern, to be sure,
but it is something that at least some Participants have asked
to have happen.

> If you don't do powershell,it's all by hand. 

Agreed. Yet some want to do it.

> (Full
> disclosure - I run the adfstoolkit.org site mentioned in the I2 spaces
> link BTW (with Leif ;). It hasn't been updated in a long time since not
> much has transpired in a long time)
> 
> Maybe this topic appears in the risks section of the doc?

I do not know yet. I want to see the discussion first.

Thanks,

Scott K

> 
> Thoughts welcome as always ..
> 
> C
> 
> 
> 
> On 2016-09-06, 9:05 AM, "Scott Koranda" 
> <>
>  wrote:
> 
> >Some InCommon Participant ADFS operators want to be able to
> >consume metadata for a particular entity by pointing at a MDQ
> >service that uses HTTPS as the transport and the trust
> >mechanism rather than XML digital signature of the metadata.
>