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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Response from Colin_NZ regarding queries on initial response to SSTC Telecon March 17th, 2015


 

Folks

 

I’ll try to answer the queries <<inline>> below by pooling responses from RealMe’s Solution Architect and Business Analyst with my own.

 

Cheers

Colin

…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………..

Colin Wallis was unable to join the call due to time zone differentials, but he sent out a message to the SSTC list that we reviewed thoroughly on the call.

https://lists.oasis-open.org/archives/security-services/201503/msg00002.html

Having the relying party also request consent of the user seemed counter to most of our deployment experience, where the user is typically only prompted for consent by the IdP. 

<<CW: In NZ from the outset, we separated login/authentication from identity verification – kind of 2 IdPs. We use the Browser based redirect profile with artifact binding for authentication.  Identity verification  uses browser redirect as well, with the identity verification IdP acting in the role of an SP from the perspective of the login service. That’s why the user is prompted for consent by the ‘SP’>>.  

 

There's a consent attribute in SAML [assertions, presumed by minute taker with little time today, dunno exactly where] that is a little "historical", but we are not familiar with how it is used in production by various deployments.  There seems to be a parallel attribute in AuthnRequests.

 

<<CW: Indeed the SP can pass a Consent attribute in SAML Authentication Request to the IdP. The product uptake of this attribute is a big question.. J.   We have not used this attribute as user’s consent is always required for RealMe Assertion Service IdP to release attributes to the SP.  We may have to honour this attribute if the Assertion Service IdP is required to send consent token in the response, or if the SP captures the consent and notifies Assertion Service IdP that consent is captured already etc.>>


The request seems to pivot around the ability to dynamically request attributes to be returned. 

<<CW: Yes>>.

 

Today, SAML is engineered to handle a free-standing attribute query with dynamic attribute request or list information in metadata designed around statically configured use cases where you know in advance what attributes are needed.

<<CW: Yes, and attribute query/response is a back channel binding/flow, rather than front channel which we need, in order to have the user in the flow for the dynamic consent ----- unless this comment is referring to another part of the SAML spec..>>


The crux of the issue, from the SSTC's perspective, is that there are actually two different kinds of attribute release mandates in the SAML specifications: advisory, like metadata, and normative, like attribute queries.  When you specify an attribute set in a query message, there are normative requirements that prevent the IdP from returning things that were not requested.  In the metadata case, it's just informational: trying to tell IdP's what release is necessary for the application to work, but without any normative rules around what is permissible.  In the attribute query case, the IdP is not required to return every attribute requested, but it acts as a filter; it's the maximum set that may be returned. 

 

They appear to want to designate a maximum set of attributes to be sent using metadata.

 

<<CW IdP isn’t really required to ask *all* attributes from the attribute provider. It depends on who is the service provider requesting for the attributes.  The service provider can only receive the attributes that they have configured for.  If the service provider wants only subset of configured attributes there is no mechanism in SAML Authentication request to indicate that to the IdP. We describe the requirement as dynamic attribute request>>.

 


We presume that the second point in the message was just about giving the user a point of consent in deciding whether attributes should be released, but it could be inline or out of band.  This may have the potential to be realized through use of the old consent attributes defined in the original SAML 2.0 specifications, without actually defining an extension if the old consent attributes in the old specification work.

<<CW: The second point in the message (to save looking it up) was [NZ has a requirement for Govt SP agencies to]. ‘invoke user consent to release displayed attributes on the wire in the message flow in the AuthnResponse’.. Yes, it was just about giving the user a point of consent in deciding whether attributes should be released. BUT  it has to be inline, not out of band (to fully eat our own dog food in the interpreting NZ privacy legislation and making it crystal clear to the user what they are consenting to because in this use case in question, it is synchronous, not asynchronous (i.e. the consent separated by time and message flow, from the act of releasing the attributes>>.


Someone will really need to look closely at the OpenID Connect specification to deeply understand what is being referenced before we can really understand how to represent the same functionality in SAML most effectively.  We had nobody with the time available on the call to volunteer to do the investigation.

<<CW: See below because the answer is in part pointing to metadata. I might try to find someone who knows both specs well. Section 5.3 of OpenID Connect Core specification talks about using scope as place holder for requesting attributes. Probably requires confirmation from those who can recite the OIDC spec in their sleep J …  >>

 


We're not sure how scope is applicable to SAML; perhaps it's closer to an audience restriction.

<<CW: Not sure but I don’t think so. To my simple mind, an OAuth scope it basically a hint to ….‘what do you want to do.. what the SSTC says above is as advisory (use of Metadata). SAML is highly reliant on Metadata to do this kind of job (as the SSTC has already noted above), so I accept we are probably not fully utilizing that avenue..  Could anything else be done outside of metadata to assist?.  FWIW, our understanding of scope in SAML is used for IdP Proxy context, which I think lines up with SSTC’s views above. OpenID Connect has a different view on the scope, as does UMA>>.

 


The other consideration is the delta between getting the specification written, and getting real world support in both implementations and deployments.  If there were a deployer who was very serious about the feature giving funding saying it was a top priority, then that would obviously influence how much time would be invested.  Our concern is that the newer specifications have not seen high uptake by the many and varied implementations of SAML, so it's unclear how much weight a specification alone would carry.

<<CW: Fair point. We would have to get.. what.. ..most of the mainstream SP SAML clients to support it?... Forgerock OpenAM, Ping Federate et al >>  


We would like to learn more from Colin about the goals here, and the extent to which they are serious about the mandate.  As a government, they may have more tools to incentivize vendors to implement features that they care most about.

<<CW: The goal is to move from static config to dynamic request (OK then....cane me now) with more use of Metadata as an accepted advisory, and release via the front channel as normative, so we can bring the user into flow. Serious? Well, serious enough, but it’s probably not die in the ditch serious as we have a clumsy work around in operation. But it ain’t pretty. More tools than the private sector? Not sure either. Maybe if the requirement was common to the Govts of CA, AU, NZ, NL..some other EU states post eID regs, then maybe there is a higher chance of incentivizing vendors>>.


We assigned no action items at this point since we're still in the information gathering phase and we're looking to Colin to have a chance to interpret and respond based on what's captured in these minutes.

<<CW: How am I doing? >>

………………………………………………………………………………………………………….

 

> 5. Assorted mail items:

Colin Wallis was unable to join the call due to time zone differentials, but he sent out a message to the SSTC list that we reviewed thoroughly on the call.

https://lists.oasis-open.org/archives/security-services/201503/msg00002.html

Having the relying party also request consent of the user seemed counter to most of our deployment experience, where the user is typically only prompted for consent by the IdP.  There's a consent attribute in SAML [assertions, presumed by minute taker with little time today, dunno exactly where] that is a little "historical", but we are not familiar with how it is used in production by various deployments.  There seems to be a parallel attribute in AuthnRequests.

The request seems to pivot around the ability to dynamically request attributes to be returned.  Today, SAML is engineered to handle a free-standing attribute query with dynamic attribute request or list information in metadata designed around statically configured use cases where you know in advance what attributes are needed.

The crux of the issue, from the SSTC's perspective, is that there are actually two different kinds of attribute release mandates in the SAML specifications: advisory, like metadata, and normative, like attribute queries.  When you specify an attribute set in a query message, there are normative requirements that prevent the IdP from returning things that were not requested.  In the metadata case, it's just informational: trying to tell IdP's what release is necessary for the application to work, but without any normative rules around what is permissible.  In the attribute query case, the IdP is not required to return every attribute requested, but it acts as a filter; it's the maximum set that may be returned.  They appear to want to designate a maximum set of attributes to be sent using metadata.

We presume that the second point in the message was just about giving the user a point of consent in deciding whether attributes should be released, but it could be inline or out of band.  This may have the potential to be realized through use of the old consent attributes defined in the original SAML 2.0 specifications, without actually defining an extension if the old consent attributes in the old specification work.

Someone will really need to look closely at the OpenID Connect specification to deeply understand what is being referenced before we can really understand how to represent the same functionality in SAML most effectively.  We had nobody with the time available on the call to volunteer to do the investigation.

We're not sure how scope is applicable to SAML; perhaps it's closer to an audience restriction.

The other consideration is the delta between getting the specification written, and getting real world support in both implementations and deployments.  If there were a deployer who was very serious about the feature giving funding saying it was a top priority, then that would obviously influence how much time would be invested.  Our concern is that the newer specifications have not seen high uptake by the many and varied implementations of SAML, so it's unclear how much weight a specification alone would carry.

We would like to learn more from Colin about the goals here, and the extent to which they are serious about the mandate.  As a government, they may have more tools to incentivize vendors to implement features that they care most about.

We assigned no action items at this point since we're still in the information gathering phase and we're looking to Colin to have a chance to interpret and respond based on what's captured in these minutes.

> 7. Next SSTC Call:
>   - Tuesday 14 April 2015.


We look forward to talking to you all then.  Take care.



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