• Created by Unknown User (schofield), last modified by Unknown User (harris) on Nov 20, 2012

Scribing Template

DATE:

20 November 2012

TIME:

3.00 - 3.45

ROOM:

Main

TOPIC:

Attributes on attributes

CONVENER:

Victoriano Giralt

SCRIBE:

Nicole Harris

# of ATTENDEES:

13

MAIN ISSUES DISCUSSED 

  1. what is the lifecyle of an attribute?  Can we attach dates to attributes to make them valid? This would divide up to: Attributes, Values and Properties.  Most common property is 'valid until'.
  2. SHAC already has the concept of a 'valid until' date.
  3. What are these properties?
    1. validuntil / expiration date,
    2. source,
    3. language (although solved in the xml namespace),
    4. provenance: self asserted (verified by issuer) / self asserted (non verified by issuer). 
    5. permittable context (health transactions, library transactions, social transactions).
  4. Valid until for attributes seems to have the most use cases attached to it.  
  5. 'validuntil' provides no assurance that this will not be overwritten before this date.

ACTIVITIES GOING FORWARD / NEXT STEPS

  1. Describe the following use cases: "student is currently studying this course but this attribute is only valid until (course end date)".  "value of student expires at".
  2. How could this be interpreted in SHAC / other schema?
  3. Can we add these use cases to the mace-dir wiki space?  They are looking for use cases / reasons to keep going. 
  4. Pass the use cases across to Kantara Attributes in Motion?

RESOURCES

If slides, websites or other pointers for information are used in the session, please attach them to this page or send them to the secretary for posting.

If you don't have an account on the TERENA wiki you can post your notes as a comment to this page - and they'll be incorporated into the notes and then deleted.

  • No labels

2 Comments

  1. Anonymous

    a use case concerning grids and federations
    For example to access grid you need a certificate. To get a certificate you can ask to TCS portal. To provide a certificate TCS portal need a federated authentication + an entitlement that attest your identity is vetted.
    This entitlement is specific for TCS and should not be used by other SP not related to TCS. But arises the case that another SP wants to know is an identity is vetted or not. Does it exist an attribute that can attest that an identity is vetted? (isIdentityVetted could be a possible attribute)

    vettingValidUntil could be an option of isIdentityVetted and could be the expiration of the identification document used for vetting

    e-mail also is necessary to TCS. You suggest an option like x-self-asserted to discard this email to be used by TCS. I suggest an inclusive option instead, for example x-vetted or x-guaranteed-by-org. In the first case you could still find invalid emails, not in the second case, hopefully.

    A further question. When IDP will provide vetted identities with vetted attributes will be still necessary to manage certificates to access grids? Could grids accept attributes coming from SAML assertions?

    --Lalla

    1. Anonymous

      Lalla,

      While technically this touches on the attribute options/properties (as an implementation detail) IMHO it's better to frame these questions in the (Level of) Identity Assurance context. Also, whether LoAs (or statements of vetting/proofing) are in fact needed on the level of individual attributes, and whether Relying Parties would be able to process those, is not clear at all, at least to some.

      The TCS personal portal use case is different, I think, as it's simply a requirement of that service that only insitutional email addresses are accepted. From that does not follow that you should send other addresses and clearly label them as such, it follows that you have to do the local processing/decision-making first and only send the correct values.
      Whether that's a good requirement by the service to have or not is immaterial here. What's important is that this is not a use case for attribute options/properties. Only a service that legitimately would use attributes of different "sub-types" (at the same time) would be an example of that – with the added restriction thrown in, that having differnt attributes for these "sub-types" is inacceptable, for some reason. Since the generic mail attribute does not specificly mean "institutional email" you'd either profile it (as is being done in the TCS case), or create a seperate attribute with the desired semantics, say, eduPersonInstitutionalMail. Coming up with a general rule when it makes sense to create a new attribute and when to "sub-class" an existing one would be an interesting excercise.
      -peter