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: Re: [security-services] Proposed Agenda for SSTC Telecon (1 September 2015)

Hi Mert,

In that case as a starter...

We tackled extensions like this in STORK1 and STORK 2.0 and went for a slightly different definition of the Requested Attribute Type. 

<complexType name="RequestedAttributeType">
     <element ref="stork:AttributeValue" type="anyType" minOccurs="0" maxOccurs="unbounded"/>
  <attribute name="Name" type="string" use="required"/>
  <attribute name="NameFormat" type="anyURI" use="required"/>
  <attribute name="FriendlyName" type="string" use="optional"/>
  <anyAttribute namespace="##other" processContents="lax"/>
  <attribute name="isRequired" type="boolean" use="optional"/>

To quote from the STORK specifications: 
"The <stork:AttributeValue> element allows the requestor to specify that the attribute requested must have one of the specified values i.e. only return this attribute if the value of this attribute value (for the subject) is one of the requested values.
This is used to request derived attributes e.g. IsAgeOver.  For example if the requestor wants to know if the subject is over 16 years old, then they can request the IsAgeOver attribute with the requested <stork:AttributeValue> of 16. If the subject was 18 the attribute would be returned in the SAML response assertion with a value of 16.  If the subject was 15 then the resultant attribute in 
the assertion would have no value.  

Note this does not cater for complex conditions such as Is Subject aged between 15 and 18. Nevertheless, if the attribute isAgeOver is requested twice, e.g. one isAgeOver(15) and the other one isAgeOver(18), the reply gives information on whether or not the subject is in this range of ages."

One problem with things like this is they may be ignored (as your document says) by the IDP.

As an aside, in the UK we are actually looking at alternatives to the SAML attribute flow to keep identity and attribute enrichment separate but that is more of a policy decision on our part rather than anything else. This is due to a UK concern that there is a distinction between attributes related to the identity of a 'person' (natural or legal) and attributes related to the entitlement of that person to access a service or complete a transaction. 

Happy to share learning from this and other SAML implementations if you think it would be useful. 

I’m part of STORK 2.0, eIDAS and eSENS all of which have an interest in this area and share a common ancestor in STORK1 if that helps as well. 



2015-09-01 16:15 GMT+01:00 Mert Aybat <mert.aybat@connectis.nl>:
Hi Adam,

Any comments or different approaches is most welcome and we are very interested in hearing them! So please share your opinions.


www.connectis.nl | Postbus 975 | 3000 AZ Rotterdam | +31 (0) 88 - 0120 222 | KvK 24444001

Connectis ontwikkelt een nieuw platform en zoekt ervaren software engineers.
Kijk op www.werkenbijconnectis.nl voor meer informatie.

Connectis, FederateNow™ en ZorgverlenerOnline zijn handelsmerken van Connected Information Systems B.V. 

Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk. Aan dit bericht kunnen geen rechten ontleend worden. Op het werk van Connected Information Systems B.V. zijn haar algemene voorwaarden van toepassing.

Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B 6NH

Tel: 07973 123 038

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