Date: Wed, 10 Feb 2010 16:41:29 -0500

10 Feb 2010 21:36:57 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

Josh> Given that we already have AAA credentials established, we can
Josh> derive a second credential which provides a PSK for TLS.
>>
>> The acceptor has the credential shared with the TAS (trust
>> authority near server for the archive). The artifact is being
>> issued by the TAC (trust authority near client). We could have
>> the acceptor start conversing directly with TAC and use EAP-GSS
>> to bootstrap a credential.

Josh> Right. This is what I was proposing with "recursive
Josh> discovery". TAS recurses through the trust graph until it
Josh> finds TAC, and they converse directly. Policy can be enforced
Josh> at any point along the trust graph so that if someone doesn't
Josh> want these entities talking, they can enforce that.

I thought you were proposing that TAS obtain a credential with TAC.
What we need for artifact resolution is for S to obtain a credential
with TAC.
So, S needs to be an X server, AAA client, artifact resolution client
and key management client.

Josh> I'm not concerned about the authenticity of the artifact; let
Josh> us assume that we have satisfied that. I'm concerned about the
Josh> authenticity of the SAML message that we obtain when we
Josh> resolve the artifact. If the acceptor does not authenticate
Josh> the IdP, it could be obtaining an assertion from an issuer who
Josh> is not who they claim to be.

Ah! My terminology failure. Can we include a hash of the SAML message
in the artifact or along side the artifact to get authenticity of the
SAML message?

Return-Path: <0 Feb 2010 22:56:13 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Wed, 10 Feb 2010 18:16:55 -0500
10 Feb 2010 22:56:13 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

Josh> That's where I started from. But I think that it is cleanest
Josh> to fold TAS into S, and then use recursive discovery to walk
Josh> the trust graph from the start. For example, if necessary S
Josh> can walk to a local TA (for name authorisation) before
Josh> exploring the trust graph outside of the local trust domain to
Josh> find TAC.

Ah, looks like we'll both be sleeping on something. Making S be
something more than a stub RADIUS client--actually having it interact
with RADIUS entities other than TAC seems esthetically bad to me.
I'll think on this.

Certainly if S talks to more than TAS, things get complicated. For
example the club really isn't in a position to kno whether S is allowed
to speak for a particular name.

--Sam

Return-Path: <1 Feb 2010 09:55:46 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Thu, 11 Feb 2010 08:44:23 -0500
11 Feb 2010 09:55:46 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

Josh> I think we need to move away from the idea of TAS or TAC as
Josh> having a special role to play, and just consider them as a
Josh> potential first discovery hop from the S and C respectively.

Josh> To use a routing analogy, we would consider an IP architecture
Josh> that required the use of a particular first hop router to be
Josh> broken. A host might have a default router for unknown
Josh> prefixes, but it should also be able to pick between
Josh> alternative routers for prefixes it does know about.

Josh> Consequently, I think it is reasonabe to think about TAS and
Josh> TAC as being the default trust path for S and C respectively,
Josh> but that if S or C know a better path they should use that
Josh> instead.

Ah! Thanks for describing things this way. It makes it clear exactly
where my concerns are.

Certainly an IP architecture that depended on using a certain first-hop
router would be of concern, although LISP and GSE do both fall somewhat
into this category. (They both have distinguished routers that a path
must go through).

my problem is with requiring S to talk to a node other than TAS. There
are a lot of good security and simplicity reasons that you want to
minimize the number of protocols, credentials and entities S needs to
talk to. There are also latency and performance reasons that you want
to avoid S needing to set up credentials in real time.

In IP, we've discovered that there are important classes of node that
should only have a default router. Many classes of small IP devices
have effectively only support for a default and localhost route. We'd
reject an IP architecture that required more complexity than that in an
end-node.

I think we should reject a moonshot architecture that requires routing
logic in servers for the same reason.

Some servers may well have complicated routing, but requiring them all
to do so seems like a bad design.

Requiring a server to engage in a key management protocol to get an
artifact is doing exactly that.

As an aside, I remain unconvinced that treating TAS and TAC as special
architectural entities doesn't simplify the model in important ways. I
definitely agree that we should support a case where TAS gets close to
S--definitely on the same machine, possibly in the same process. I'm
not sure though that we want to lose the model distinction.

Return-Path: <1 Feb 2010 09:55:46 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Thu, 11 Feb 2010 08:44:45 -0500
11 Feb 2010 09:55:46 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
I will be unavailable until our 1500 call.

Return-Path: <1 Feb 2010 21:01:53 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Fri, 12 Feb 2010 12:46:13 -0500
11 Feb 2010 21:01:53 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
I think we're on the same page regarding actors. I didn't see anything
new in your definition of actors.

I think you may be confusing BGP confederations with BGP communities.
As I remember, a BGP community is an attribute attached to a route used
for local policy with no protocol level interpretation. A confederation
is a set of ASes aggregated together to reduce BGP-level peering
complexity. Or perhaps BGP communities are operationally used as you
describe?

I think separating the KNP and the TNP is a very good idea. The KNP is
what we use for setting up a key used between a SAML metadata consumer
and target entity. That seems like a good name for that protocol.
While the TNP has the same basic structure as the KNP it probably
carries different XML and is focused on AAA relationships not SAML
relationships. There may be some links between the two protocols.

While I've read your comments about the trust graph and TML, I have not
fully digested them. In particular, I don't understand the security
implications of the system, nor do I understand caching and performance
implications. I also don't understand how much trust discovery is
actually required. For example it seems like the European academic case
could be handled relatively simply. Ask TAS through an untrusted
channel what authorities it accepts. Give that list to your national
federation and move from there. In other words, the more assumptions we
can make about the graph, the simpler our task. So, while you have a
good theoretical model, I'm not sure how general of an implementation we
will need nor how soon.

Return-Path: <2 Feb 2010 22:10:50 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Fri, 12 Feb 2010 17:21:31 -0500
12 Feb 2010 22:10:50 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

Josh> I understand, in particular, your skepticism concerning trust
Josh> path discovery. I guess this boils down to personal opinion
Josh> about the likely future scale of federated systems. You're
Josh> probably right that we could live without trust path discovery
Josh> purely within the European Higher Education community over the
Josh> next 2 or 3 years. However - on the evidence of the adoption
Josh> of federated identity within the HE community - I believe that
Josh> we're in the early stages of exponential growth. While the
Josh> absolute numbers are nowhere near Internet-scale at the
Josh> moment, I believe that it's only a matter of time. It will
Josh> escape the petri dishes of .gov, .edu, large .com, etc, and it
Josh> I think it would be prudent to be prepared.

There we're in complete agreement. However, I view the need to support
this sort of trust path discovery as very much a next stage issue. The
rest of the project seems squarely in the category of engineering work.
The trust path discovery may well be research. So, I'm finding that I
need to approach the trust path discovery and try and understand
requirements and use cases. Then I'll want to decompose it, build
logical interfaces, and understand how they fit together. At that point
I'll be better able to discuss specific mechanisms.

--Sam

Return-Path: <2 Feb 2010 23:12:52 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Fri, 12 Feb 2010 18:28:10 -0500
12 Feb 2010 23:12:52 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

>> There we're in complete agreement. However, I view the need to
>> support this sort of trust path discovery as very much a next
>> stage issue. The rest of the project seems squarely in the
>> category of engineering work.

Josh> Agreed. It would be nice to have a story for 3 to 5 years
Josh> hence, but as you say it is important that we focus on
Josh> engineering solutions to demonstrable problems of today. I
Josh> will try to control my enthusiasm for fixing tomorrow's
Josh> poorly-defined problems :-)

Well, let's just try to channel it into defining the problems:-)

Return-Path: <pplications at IETF 7>
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Fri, 12 Feb 2010 19:34:00 -0500
applications at IETF 77
Message-Id: <[email-masked]>
To: [email-masked]
Comments: To: [email-masked], [email-masked], [email-masked]

I've been working with JaNet(UK) on providing a federation solution for
client applications such as mail readers, filesystem clients,
XMPP clients and the like. There are fairly good solutions such as Open
ID, Information Card and SAML for web applications. Within an
enterprise, you have Kerberos.

JaNet(UK) runs one of the world's largest SAML federations. As their
customers are beginning to take advantage of federated access for web
applications they are also asking how they can gain the same flexibility
for client-server applications. This customer demand appears to have
traction across the entire European academic community. I suspect that
it may find traction within enterprises and other environments.

We'd like to have a bar BOF at IETF 77 in California with a goal of an
actual BOF this summer in Europe at IETF 78. We invite you to join our
mailing list at
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community where
we can discuss timing.

We plan to discuss the general problem and a proposed solution at the
bar BOF. I've already prepared a feasibility analysis for JaNet(UK)'s
solution; the analysis does discuss the problem some, gives an outline
of the solution and discusses technical issues and required standards
work in detail. By IETF we'll have a use case paper, an internet draft
on the solution,and a slide set.

we look forward to your input. You can find a bit more detail on my
blog at http://www.painless-security.com/blog/2010/02/12/moonshot1
You can find the feasibility analysis at
http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf

Thanks,

Sam Hartman
Painless Security

Date: Thu, 18 Feb 2010 11:18:03 -0500
Subject: Re: SAML RADIUS Binding
To: [email-masked]

Josh Howlett wrote on 2010-02-18:
>> So as I suspected, this is about message size? XML == bad fit
>> for size constrained protocols.
>
> EAP doesn't have any size constraints, but RADIUS (a common EAP
> transport) does. A RADIUS message is (essentially arbitarily, AFAICT)
> limited to 4kb. In some circumstances it is possible to fragment large
> payloads over multiple RADIUS messages, but only if the payload is part
> of an on-going conversation. The last payload (which in this context
> will contain a SAML response/assertion) must fit completely into the
> final RADIUS message.

Ok. Reminding myself of the roles in play here, is the RADIUS traffic
(ignoring proxies) basically between the IdP and an SP of some kind? If the
semantics are such that the assertion was delivered as part of that
conversation, one possibility would be to deliver it as an assertion
reference, not an artifact, and just dereference it using the Assertion
lookup profile that's already in the spec, via HTTP. It really depends on
the security semantics in play.

One point to make is that if there's no AuthnRequest, there probably doesn't
need to be a Response. So this is probably just an Assertion anyway.

-- Scott

Date: Thu, 18 Feb 2010 14:32:29 -0500
Subject: Re: SAML RADIUS Binding
To: [email-masked]

Josh Howlett wrote on 2010-02-18:
> That makes a lot of sense. If you recall, the original approach was to
> avoid authentication (which would imply a turtle issue) of the call-back
> responder by attempting to match a hash claimed in the artifact to the
> SAML message that it resolves. I believe we can achieve a semantically
> equivalent effect by incorporating the same hash in the AssertionIdRef
> value.

The AssertionIdRef is basically just consumed by the relying party, there
aren't any rules in the spec for processing it or decorating it. It's
designed for cases in which any concerns about the context of the reference
would be handled by that context. For example, in WSS, you can sign a
reference such that the actual signature is over the result of dereferencing
it, to maintain integrity.

I guess I just don't understand the need to avoid authentication. Without
authenticaton of the issuer, you can't trust the assertion anyway, it's just
data at that point. I'm assuming that the "turtle" problem is dealt with by
using traditonal trust mechanisms or by recursing things such that you get
an assertion from some other party to let you authenticate the first one.
You have to trust somebody to start with, and the runtime manifestation of
that is authentication.

-- Scott

Return-Path: <3 Feb 2010 16:58:55 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Mon, 22 Feb 2010 09:37:48 -0500
13 Feb 2010 16:58:55 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
Replying to the question about artifact resolution given that SAML
requires peer-entity authentication.

First, I think the right technical approach is to ignore the RADIUS MTU
issue.

If that proves problematic, I think including endpoint channel bindings
is preferred to establishing a key to include in the access-accept.
These bindings will be sufficient for authentication--in effect you're
just telling the other end what cert to expect.

Return-Path: <8 Feb 2010 00:01:18 -0500\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Mon, 22 Feb 2010 10:04:04 -0500
18 Feb 2010 00:01:18 -0500\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Scott" == Scott Cantor <[email-masked]> writes:

>> Josh previously wrote:
>> > Bad news. As I suspected, it is a requirement that the
>> call-back used to > the resolve the artifact is authenticated at
>> the transport layer.

Scott> Well, it doesn't have to be the transport layer...you can
Scott> sign the messages, for example. But the protocol as designed
Scott> is for two SAML peers to interact and authenticate each other
Scott> during the exchange so that the artifact is consumed by the
Scott> intended party and the message can be trusted.

If signing the message is acceptable, then sending a hash of a message
over an integrity protected channel between the two SAML peers should be
OK too.

Date: Mon, 22 Feb 2010 10:12:06 -0500
Subject: Re: SAML RADIUS Binding
To: [email-masked]

Sam Hartman wrote on 2010-02-22:
> If signing the message is acceptable, then sending a hash of a message
> over an integrity protected channel between the two SAML peers should be
> OK too.

The signature is for authentication of the issuer of the message. I don't
really have enough experience to understand how you can substitute different
mechanisms for that, but sending around hashes doesn't seem to be an
authentication solution unless it's an HMAC. Maybe that's what you meant.

-- Scott

Return-Path: <essage of \"Mon, 22 Feb 2010 10:12:06 -0500\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Mon, 22 Feb 2010 11:06:56 -0500
message of \"Mon, 22 Feb 2010 10:12:06 -0500\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Scott" == Scott Cantor <[email-masked]> writes:

Scott> Sam Hartman wrote on 2010-02-22:
>> If signing the message is acceptable, then sending a hash of a
>> message over an integrity protected channel between the two SAML
>> peers should be OK too.

Scott> The signature is for authentication of the issuer of the
Scott> message. I don't really have enough experience to understand
Scott> how you can substitute different mechanisms for that, but
Scott> sending around hashes doesn't seem to be an authentication
Scott> solution unless it's an HMAC. Maybe that's what you meant.

No, not an HMAC. Alice tells bob over an authenticated channel that
she's going to send him a message with hash h. Later, through an
arbitrary channel that better supports large messages than the
authenticated channel Alice sends a message with hash h. On receiving
that message, Bob knows it came from Alice because if a strong
cryptographic hash is used, then no party can find a message other than
the one Alice constructed that hashes to h.

This is effectively exactly what a digital signature does. A signature
is a hugely expensive RSA channel that really cannot easily send
messages larger than the key size. We want to sign a message larger
than a key (and get several other properties besides).
So, using our RSA channel, we send a hash of the message. Then using
any channel of our choice, we send the message.

--Sam

Date: Mon, 22 Feb 2010 11:14:31 -0500
Subject: Re: SAML RADIUS Binding
To: [email-masked]

Sam Hartman wrote on 2010-02-22:
> No, not an HMAC. Alice tells bob over an authenticated channel that
> she's going to send him a message with hash h. Later, through an
> arbitrary channel that better supports large messages than the
> authenticated channel Alice sends a message with hash h. On receiving
> that message, Bob knows it came from Alice because if a strong
> cryptographic hash is used, then no party can find a message other than
> the one Alice constructed that hashes to h.

Ok, this time you said "authenticated channel", while before you said
"integrity-protected". That's why I asked.

-- Scott

Return-Path: <essage of \"Mon, 22 Feb 2010 11:14:31 -0500\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Mon, 22 Feb 2010 15:31:11 -0500
message of \"Mon, 22 Feb 2010 11:14:31 -0500\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Scott" == Scott Cantor <[email-masked]> writes:

Scott> Sam Hartman wrote on 2010-02-22:
>> No, not an HMAC. Alice tells bob over an authenticated channel
>> that she's going to send him a message with hash h. Later,
>> through an arbitrary channel that better supports large messages
>> than the authenticated channel Alice sends a message with hash h.
>> On receiving that message, Bob knows it came from Alice because
>> if a strong cryptographic hash is used, then no party can find a
>> message other than the one Alice constructed that hashes to h.

Scott> Ok, this time you said "authenticated channel", while before
Scott> you said "integrity-protected". That's why I asked.

I think the terms are more or less interchangable when applied to a
channel. Integrity protection is definitely useless without
authentication. To be pedantic, it seems that RFC 2828 does not require
that authentication service implies data integrity service, but does
require that data integrity service implies authentication service. So,
if you accept that lexicon, my original statement was more correct.

--Sam

Return-Path: <2 Feb 2010 18:17:33 -0000\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Mon, 22 Feb 2010 15:32:37 -0500
22 Feb 2010 18:17:33 -0000\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

Josh> Sam wrote:
>> First, I think the right technical approach is to ignore the
>> RADIUS MTU issue.

Josh> Would this be acceptable to IETF? Ot are you talking about the
Josh> implementation?

I was talking about the IETF. However this statement was made before
reading your comment that an expert on RADIUS recommended against
ignoring the MTU issue.

Date: Tue, 23 Feb 2010 19:11:04 -0500
Subject: Re: SAML RADIUS Binding
To: [email-masked]

Josh Howlett wrote on 2010-02-23:
>> Is there any harm in processing or decorating it such that we
>> can obtain the kinds of semantics we've been discussing?

There's no harm unless the processing is expected to be performed by the
client of the URL. The URL in question is expected to be opaque to the
client with the exception of a convention to construct a URL if you know the
endpoint and the Assertion ID.

A different set of rules could be created with a different binding layered
on top of the original one.

> Reading SAML2Core section 2.3, would it be cleaner to use
> AssertionURIRef instead, defining some namespace for this purpose?

I don't think there's much difference, really.

> Thinking aloud, might there also be some advantage in using the SAML URI
> Binding rather than the Assertion Request Profile? The SAML URI Binding
> is somewhat more lightweight.

It's more lightweight at the cost of limiting the security features to HTTP,
rather than SOAP.

If I understand what you're thinking about, I think all that is moot here
because you're looking for different places to put the authentication of the
peers and trying to exchange a hash along with the data you want to pass
because the channel is already supposed to be authenticated.

-- Scott

Date: Wed, 24 Feb 2010 10:06:47 -0500
Subject: Re: SAML RADIUS Binding
To: [email-masked]

Josh Howlett wrote on 2010-02-24:
>> It's more lightweight at the cost of limiting the security
>> features to HTTP, rather than SOAP.
>
> Ok, I think that's probably a feature in this context. I can't see what
> value SOAP adds.

A framework for message-level authentication, basically, in particular the
ability to use SAML assertions as a credential (recursive use, basically).
There really is nothing else (in wide use) that supports the use of SAML
that way on a message-oriented basis.

-- Scott

Date: Thu, 25 Feb 2010 14:27:17 -0500
Comments: cc: [email-masked], [email-masked]
To: [email-masked]
Folks, I've been talking to Vumip Khasnabish who is working on
organizing a cloud computing bar bof. It seems that having cloud
computing and federated authentication at the same time would be a bad
idea: I suspect a lot of us want to go to both. Vumip was hoping that
the clouds bof would land on Wednesday. If that happens I'd like to
meet on Thursday.

In terms of timing, I've never done this before. Do I want to do
something like 9 PM-10:30 so people can grab a bite to eat before and so
that those who wish may join the discussion of IPv6 deployment that will
be ongoing by the time we conclude?

--Sam

Date: Thu, 25 Feb 2010 21:36:15 +0100
To: [email-masked]
On Feb 25, 2010, at 8:27 PM, Sam Hartman wrote:

Hi Sam,

Either earlier and grab something to eat and keep the discussion going =
afterwards or your proposal work for me.

Klaas

> Folks, I've been talking to Vumip Khasnabish who is working on
> organizing a cloud computing bar bof. It seems that having cloud
> computing and federated authentication at the same time would be a bad
> idea: I suspect a lot of us want to go to both. Vumip was hoping that
> the clouds bof would land on Wednesday. If that happens I'd like to
> meet on Thursday.
>=20
> In terms of timing, I've never done this before. Do I want to do
> something like 9 PM-10:30 so people can grab a bite to eat before and =
so
> that those who wish may join the discussion of IPv6 deployment that =
will
> be ongoing by the time we conclude?
>=20
> --Sam

Date: Fri, 26 Feb 2010 16:38:46 -0500
Subject: Re: What do we use SAML request for?
To: [email-masked]

> Here's what I think we need out of the SAML request. I think it
> provides a place for S to indicate what attributes it needs. First,
> is this correct? Secondly, is there anything else that our particular
> use cases get out of a SAML request?

I think the way to answer that is best handled by starting with what you
want to get in return, and then in parallel setting out the assumptions made
about what knowledge of the user exists between S, the entity making the
request (if it's not S), and the IdP.

The main thing we have to do is determine the "fit" between those answers
and the existing protocols in SAML.

-- Scott

Date: Fri, 26 Feb 2010 18:23:02 -0500
Subject: Re: What do we use SAML request for?
To: [email-masked]

> At the risk of generalising, I think it is interesting to consider
> whether we can extrapolate from today's Web SSO practices,
> particularly as in the use-cases we're not using SAML for
> authentication (where we might care about LoA etc); only as a source
> of attributes. The SAML IdP, consequently, says what goes and what doesn't
and
> the request is moot.

Well, it's not moot because of the identifier question, but yes, I thought
about mentioning that.

The issues there are essentially whether users can consent in real time,
and/or whether requirements from the service's end vary dynamically. Without
one of those cases, you get pretty much nothing from requesting specific
attributes, and in fact the Shibboleth IdP doesn't currently handle queries
that specify them. (It should/will at some point soon.)

-- Scott

Date: Fri, 26 Feb 2010 20:39:14 -0500
Subject: Re: What do we use SAML request for?
To: [email-masked]

>> whether requirements from the service's end
>> vary dynamically.
>
> When you say dynamically, do you mean faster than requirements can be
> managed out-of-band?

Yes, that's a better way of saying it.

-- Scott

Date: Sun, 28 Feb 2010 15:21:02 -0500
Subject: Re: Consent (was RE: What do we use SAML request for?)
To: [email-masked]

> I find the consent issue particularly interesting (bear with me...). One
> of the benefits that we get from the browser-bound bindings is the
> opportunity to interrogate the user about things like consent.

Yes, for a lot of people that's *the* issue that argues for hacking WebSSO
or OAuth to do basically anything you have to do.

> The Interaction Service is a fairly simple spec, but there are probably
> other approaches we should also consider. Ideas welcome!

The original service in Liberty that I was familiar with had basically no
meaningful support for the back channel. It had the ability to redirect you
(web style, basically a lot like OAuth) or to tunnel information back from a
service through the service's client, and then on to the original web
client. Security-wise, that model was of course quite silly, since you were
trusting the service that needed consent to relay your (unauthenticated)
indication of consent.

The last time this came up, I was given the impression that the later
versions of the Interaction Service had other options that were more secure,
but I haven't actually read it recently.

It seems like your secure tunnel between the home domain and the supplicant
offers a way to deal with this, but one issue is that the thing at the end
of the tunnel isn't likely to be the IdP, so there's more glue needed.

-- Scott

Return-Path: <essage of \"Sun, 28 Feb 2010 15:21:02 -0500\">
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Sun, 28 Feb 2010 15:34:59 -0500
message of \"Sun, 28 Feb 2010 15:21:02 -0500\")
Message-Id: <[email-masked]>
To: [email-masked]
MIME-Version: 1.0
>>>>> "Scott" == Scott Cantor <[email-masked]> writes:

Scott> It seems like your secure tunnel between the home domain and
Scott> the supplicant offers a way to deal with this, but one issue
Scott> is that the thing at the end of the tunnel isn't likely to be
Scott> the IdP, so there's more glue needed.

Another issue is that GSS and EAP basically have no concept of this at
all. You could potentially define a tunneled EAP method for this
conversation but it's definitely going to be ugly and a significant
change to whatever you're looking at.