[OGSA-AUTHZ] checkpointing the discussion on VO attributes

Wed Jan 30 10:23:11 CST 2008

On Tue, 2008-01-29 at 10:20 +0100, David Groep wrote:
> 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
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 at 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 at vo
> >>   </saml:AttributeValue>
> >>   <saml:AttributeValue xsi:type="xsd:string">
> >>     SoftwareManager at 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 at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> 
> 