Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Administration:
    1. Roll Call
    2. Agenda Confirmation
    3. Approval of Minutes: AIM WG Minutes 04-September-2013
  2. Discussion / Action Item Review
    1. Attribute Provider Certification?
    2. Periodic Table of Trust Elements (see "Misc. Documents" - https://spaces.internet2.edu/display/scalepriv/Useful+reference+documents)
    3. Review of charter
      1. AMDG report review
      2. matching our charter to the Kantara "why"
  3. AOB
  4. Adjourn

...

  • At IIW, there was a lot of discussion around the concept of an Attribute Provider; almost every diagram included this concept, an entity that provided attributes at some level of assurance
  • A parallel discussion, within the authN space, we have a few defined points: 800-63, LoAs, various other concepts in the authN space.  There is nothing like that, no clearly defined points, in the Attribute Provider space.  We do have the attribute ecosystem work, the periodic table just discussed, but there is a nice, gaping hole for some form of definition around how do you work with an Attribute Provider, how do you define them; some kind of work similar to what the IAWG put together for the CSP accreditation .  We could build out something that defines what kind of things need to be reviewed to bring an AP in to a Trust Framework
  • When we started the group, we were aiming for the best practices for an Attribute Broker, and this covers the same space but makes it a bit more general to talk about the issues surrounding both the attributes and the Provider itself; need to address the relationship of the Provider and the other entities in the space
  • Questions/comments?
    • how do you differentiate between an Attribute Provider and an Attribute Verifier?  the difference may encompass consent, confidence, others.  Is that a valid distinction?
    • what LoA issues may lurk here?  what about the bindings between children and parents, children and teachers (COPPA regulations) which in turn feed things like parental consent for a student to join a chatroom
      • this is all loosely defined at the moment, or defined in a domain specific way
    • as an alternate model, regarding AP and AV, some can look at two different kinds of attributes - authoritative attributes from the Providers themselves vs. registered attributes where they are not the authoritative source but they will assert the attributes - these are attributes they included in their databases that have been verified in someway (looked at Passports, Driver's License)
      • as the ecosystem starts growing, there will be different levels of attributes available and it will be harder to understand/verify the level of confidence of those attributes; in particular, as people see business opportunities and sell attributes, this becomes more important; and when we talk certification, there is liability involved
      • also note that what's authoritative in one vertical might not be authoritative in others; might be different even by federation within the same vertical; we need the framework to say who is providing what by what terms, possibly by a provider-by-provider level
      • Brokers have to be part of the discussion; on the one hand, you would expect the Broker to be held to the T&Cs of the underlying provider, but they also bring in an additional level of abstraction; we need to discuss the issue around when and how the Broker may be able to change the level of confidence on the assertion
  • there does seem to be some support in looking at the issues around APs, the Terms and Conditions around that, and this should be captured in the AIM WG Charter
Review of charter
  • AMDG report review
  • matching our charter to the Kantara "why"
  • Allan and Heather to work on the draft charter

...