Hi Valerio, all,
Valerio Venturi wrote:
Ok, looks like we have agreements on most of the point. Who takes the pen? Blair, DavidG, what about the chances that this may become an OGF doc? If there are some, we'll go with the OGF doc template.
This is certainly a document that is clearly in scope for OGF doc and on track for rapid progress: there has been extensive discussion, community consensus is forming well, and is very relevant and timely.
As a process issue, Blair and I do propose that this be done in a 'quick' dedicated working group, instead of lumping it with the OGSA-AuthZ group for which it (1) would mean a change of charter and (2) which is already stuck with a lot of documents that need to be finished as well. And doing a quick dedicated WG for this really does not take that long: with the ideas at hand we can do a BoF in 2-3 weeks in Boston, supported by the email list for those that cannot physically be present, and get the working group chartered right away. With just this one deliverable, that will be quick and clean. Doing this during the Security Area meeting which is already scheduled also not not need any additional effort on behalf of the coordinators of the document. And, personally, I think Valerio as a (co)chair of the such group would make things along very well.
It can also help reduce confusion in oGF as a whole as it does not necessarily have bear the OGSA label in the name of the group, and the scope of this document is wider anyway.
Valerio, would you support this idea? Blair and I are very willing to help getting this started. Sounds good. Another similar issue has been issued here an there, defining XACML attributes and obligation needed for authorization services. What about including that too? This is something that those implenting authorization services are facing, as you know, and community consensus would be very important. Also, deciding that may help in sorting out one of the main concern with
On Tue, 2008-01-29 at 10:20 +0100, David Groep wrote: the current authz decision spec, that is, having or not having attribute and obligation definition in the profile. If we can be sure to have those defined in a separate document to be released soon, may be it's ok to remove them from the current spec. DavidC, what do you think about that? For what concern (co)chairing, I'd like very much if you and Blair think it would help, but I need to check with my management. Given the unclear destiny of the project I've benn working on, I'm not sure I'll be working 100% on authorization starting from May. Until then, I'm available for bootstraping things. Valerio
Comments welcome!
DavidG.
Valerio
On Mon, 2008-01-21 at 15:22 +0100, Valerio Venturi wrote:
Hi, I'll try to checkpoint the discussion had so far.
As Krzysztof is planning to serve more than one VO with the same service, we cannot have a one to one relationship between entityIDs and VOs, this imply the need of having a VO attribute. Which was also more or less David's concern, an authority being able to assert whatever it wants. If we go wiht this, the VO attribute stays. We have two proposal so far. Tom suggested to use the MACE-Dir eduPersonScopedAffiliation attribute
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" FriendlyName="eduPersonScopedAffiliation"> <saml:AttributeValue xsi:type="xs:string">member@voName </saml:AttributeValue> </saml:Attribute>
while in our first draft Krzysztof and I suggested the use of a specific
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="vo" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> voName </saml:AttributeValue> </saml:Attribute>
Let's try to agree on one.
There were concerns about Tom's proposal to use Grouper to express groups, specifically about the contents being an URN. Anyway, the specification doesn't mandate them to be URN, it recommends to use URIs is uniqueness is to eb achieved.
Other concerns with using this?
Still we have no suggestions for expressing roles, apart from the initial (but I have made the group syntax homogeneous with the above)
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="role" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> VO-Admin@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@vo:group:subgroup </saml:AttributeValue> </saml:Attribute>
that seems to receive more favor than the one with the scope attributes.
What problems can you see with that?
Valerio
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg