[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on Federated Provisioning, Draft 0.1
Comments on OASIS SPML v2 - Federated Provisioning, Draft 0.1 ------------------------------------------------------------- 1. The account object appears central to most of the use-cases. (a) Should the use-case document provide an (abstract) definition of account? For example, the SAML glossary provides the definitions Account: Typically a formal business agreement for providing regular dealings and services between a principal and business service providers. I am not suggesting that this has the right level of detail, only that it might provide a starting point. (b) Would this effort ultimately provide concrete XSD schema for an account? I can see this might be challenging but at the same time it would help a lot with OOB interoperability. 2. Similar questions apply to "federation relationship between accounts"(Use-Case 2.6). (a) I am not sure exactly what is referenced here. Do you mean account linking? Again, from the SAML glossary: Account Linkage A method of relating accounts at two different providers that represent the same principal so that the providers can communicate about the principal. Account linkage can be established through the sharing of attributes or through identity federation. Federated Identity A principal's identity is said to be federated between a set of Providers when there is an agreement between the providers on a set of identifiers and/or attributes to use to refer to the Principal Identity Defederation The action occurring when Providers agree to stop referring to a Principal via a certain set of identifiers and/or attributes. Identity Federation The act of creating a federated identity on behalf of a Principal. (b) Would there be concrete schema defined - e.g., <saml:nameidentifier> and/or <saml:attributestatement> - for use during account linking? (c) I guess it is assummed in cases 2.1, 2.2 and 2.4 that the accounts created at the SP are linked to the accounts at the IdP, right? 3. Section 2.6 provides a use-case for "account linking" between distinct accounts. Shouldnt there also be a use-case for "account de-linking"? Such a use-case would also be applicable in cases where the IdP provisioned accounts at the SP but does not want (or have the administrative privilege) to delete them. 4. (a) I assume this case could also be generalized to the N-case (instead of two service providers) (b) Are two interactions always required at every SP? It seems to me that there is also a case when it should be possible to simultaneously provision an account and initialize it with relationships to other accounts. I guess a pre-condition would be that the SP accepts account numbers or handles that originate from the IdP. [SAML glossary] http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]