[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Minutes from 18-Sep focus concall
Minutes taken by Gavenraj. Focus meeting - 18 Sep 2001 --- - Straw poll on toll for Substituion groups - Intermediary, etc. - multiple name identifiers -- Hal - Straw poll on tool for substition groups - Reads schema and builds classes (e.g., in Java) - Populate data structure from XML - Elimantated writing any parsing - Caster, an open source, does not support substitution groups - Phil - Take out substituion groups and replace with choice groups. - Relevant in certain applications -- Irving - Current schema has one or more subject - Based on XACML - How do you see it playing it out here - Don't want to have equivalent in there - When their are more than one subject - Role would be defined -- What does go next?? - Had a problem with equivalent - Need to rewrite section -- Irving - Potential use case where assertion applied to combination of subject. Subject 1 is requester and Subject 2 is receiver. - Carlisle: Requestor would be put somewhere else in the assertion. - SAML should only have one n and one subject in assertion -- Phil - Not suggseting we change cardinality, but in the case of a subject field where it defines more than one (1) principle, name gets specified jointly. - Not providing level of support if you are doing a set of users. -- Irving - We should revisit what subject confirmation is. - What happens if we have 3 or 4 entities, we want consumers of SAML information -- Should be left open for people who use the specification. - Carlisle: Should not define what semantics should be. - Bob: Two subject are the same: attribute assertion should define this. - Phil: log file name may be different than person represented (e.g., Phillip Hallam Baker is being displayed but phbaker is displayed in the log file) - Equiavlent to subject - alt name - Bob: Should use as a Attribute assertion so we don't have multiple subject fields. - Prateek - Would be really useful to only use this information within one assertion. - Bob: If you know name, you can code to find it. If you don't, you will have trouble. - Prateek: Multiple assertions may not cause extreme confusion. Relying party issue challenge to sender. How is it implemented is out of scope. - Bob: Subject of Confirmation is the relying party to use. - Irving: Subject of Confirmation is that assertion is meant to be sent by the sender (generator of assertion). - We must not build reliability model for issuers. - Bob: Subject Confirmation to relying party that attacks... - Condition is represented by holder of key. Confirmed holder of key before relying. - To Carlisle's response, should be careful if having something that looks like subject-alt-name. - Irving: Implications may be spreading. A single subject and optional list of attributes and requesting authority send back attributes about that subject. - Marlena: You could put artifact in current schema - Spawn off of Bob Blakely's email. Create thread with help from Irving.!!! - Close of meeting.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC