Refeds


Subject Re: stable reference for Scope?
From Leif Johansson <leifj@xxxxxxxx>
Date Fri, 05 Apr 2013 14:41:14 +0200

On 04/05/2013 02:32 PM, Stefan Santesson wrote:
> Thanks Ian,
>
>
> This cleared most, if not all of my questions.
>
> I just have one additional question/concern, which you in a way already
> answered.
>
> My question is how the parties knows that an attribute is scoped.
> Reading the spec you linked I find two ways so signal this within an
> attribute, either using a Scope attribute if a
> "urn:mace:dir:attribute-def" style AttributeName is used, or by using an
> "@" separator if an OID style AttributeName is used.

The rp and idp have to agree on this oob - a @-sign may occur for
other reasons than scoping. In practice this is handled in the attribute
profile for a particular federation.

Maybe a note about this would help make this clear...
>
> I first misinterpreted that the SP metadata would contain some information
> in the Scope element to signal what attributes that is treated as scoped
> by the SP, but that seems to not be the case.
Nope - some deployments tried sending 'Scope' in an attribute
in the XML but that had deployment issues.


> This makes the concept indeterministic for the IdP and AA as far as I can
> understand it. What if the SP accept an e-mail address attribute that is
> not treated as scoped (can be any e-mail address from any domain), but
> also demands an organisational identifier "id@org_id" which has a scoped
> org_id or domain. 
>
> Now how can the IdP or AA, know that it can meet the needs of that SP?
>
> Or is it the thought that the SP checks the metadata of the IdPs and AAs
> before sending a request to verify that it meets the needs of the SP?
>
> I can see that working for AA, but for IdPs it might be problematic if
> this is not integrated with the discovery service. As far as I see it, the
> discovery service have no means of matching the need of the SP with the
> capability of the IdP with respect to scoping and might allow the user to
> select an IdP that can't provide the appropriate scope.
>
> /Stefan
>
>
> On 4/5/13 11:39 AM, "Ian Young" <ian@xxxxxxxxxx> wrote:
>
>> On 4 Apr 2013, at 16:09, Stefan Santesson <stefan@xxxxxxxxxxx> wrote:
>>
>>> The Scope element is a string with an optional regexp attribute
>>> (boolean).
>>> The exact meaning of setting the regexp attribute to true or false seems
>>> missing. I can only guess that true means that the string holds a
>>> regular
>>> expression, but have no clue what the value of scope would be if regexp
>>> is
>>> false.
>> It's the literal scope value.  I have extended the text in this area; let
>> me know if everything is clearer now.
>>
>>> Also, how is the scope element associated with any attribute?
>> The service provider knows (through configuration) which attributes are
>> to be treated as having scoped values.
>>
>>> How is this used to limit certain values of certain SAML attributes from
>>> certain IdP or AA?
>> The SP looks at the Scope elements applicable to the role the attributes
>> were issued from.  For example, if the attributes came through a
>> back-channel communication with an IdP's AttributeAuthorityDescriptor,
>> any Scope elements on that descriptor AND any on the parent
>> EntityDescriptor would apply.
>>
>>> The expression: "the scope component of each attribute value received"
>>> is
>>> unclear to me. Does this mean that SAML attribute's attribute value
>>> includes explicit scope information?
>> The way that the value and scope components of a scoped value are carried
>> in SAML is defined in this document:
>>
>> http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attribute
>> s-200804a.pdf
>>
>> Section 2.3 describes the two different conventions used in SAML 1, and
>> section 3.3 covers the much simpler situation in SAML 2.0.
>>
>> Hope this helps,
>>
>> 	-- Ian
>>
>>
>>
>