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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: RE: [saml-dev] Front-channel AttributeQuery Profile


Josh Howlett wrote on 2009-11-11:
>> Would it be a good idea to omit the NameID, and use
>> Subjectconf as sender-vouces or bearer... Something like
>> this? Better ideas appreciated....

I'm generally uncomfortable with the idea that using even more bearer-based
messages is a good idea. It seems to me that the only (good) reason to use
the front channel is to deal with consent, so I like the idea of separating
out the consent problem from the query, personally.

Every time you move the client around and rely on bearer security, you just
open new attacks. By limiting it to one assertion up front, and then relying
on a shared identifier (which can easily be an encrypted/changing reference
and include requirements to present the original assertion as a HoK proof
token), the query doesn't open up new exposures.

Just MHO.

> How about defining a new NameID which takes no value, but whose presence
in
> the request indicates that the SAML Issuer must return a statement within
> the assertion which takes a value that names the subject of the enveloping
> assertion. It's fairly ugly, but...

I don't think it's necessary. There's no problem to solve, really. The
requester just has to include a value for the NameID and it's really up to
the AA to decide what to do with it. It could be a transient, for example.
The profile could even explicitly require asking for bearer confirmation in
the response, and require the AA to interpret the presenter as the subject
(assuming authentication).

-- Scott




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