[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Von Welch
vwelch at ncsa.uiuc.edu
Tue Feb 13 15:01:32 CST 2007
David,
I agree one can conceive of a scheme to do this consistently (as
you have below). It's two other issues:
1) This assumes all IdPs will provide the same identifiers and
attributes to all Shib-CA instances. This is a practical issue.
2) This assumes all Shib-CAs should issue the same name for the same
user. This may be more of a philosophical issue.
I have to admit you have me thinking about #2, and I will do so more
before responding in more depth. But I still think #1 is a show-
stopper in any case.
Von
On Feb 12, 2007, at 12:46 PM, David Chadwick wrote:
> Hi Von
>
> I dont think it is at all difficult to conceptually design a scheme
> for the following reasons:
>
> i) Each IDP must already uniquely identify each of its users,
> otherwise it could not function correctly. How this is done is a
> local matter, and we dont really care. All the IDP needs to do is
> to provide this local name of the user to the CA. Lets call this a
> sequence of any attribute value pairs that the IDP wants it to be.
>
> iii) Each IDP already has a globally unique DNS name. This is
> easily converted into a DN using the DC naming scheme e.g.
> kent.ac.uk becomes dc=kent, dc=ac, dc=uk
>
> iv) the CA simply concatenates the IDP's DN with the user's local
> name (sequence of attribute value pairs) in order to get a globally
> unique DN for the user. Each CA applies this same simple algorithm.
>
> So conceptually it is easy to design the scheme and the algorithm.
>
> Practically however there may be some difficulties due to the
> limitations of some PKI software to cater for any arbitrary
> attribute types in a DN. (Some PKI software might not care because
> all they do is a simply binary comparison of DNs, as mentioned by
> Peter Guttman. But others might try case insensitivity or similar
> normalisations.) This however should not nullify the scheme. First
> we should look at the software limitations that are currently
> present, and once we know what these are, either try to fix the
> software or determine best work around solutions e.g. by defining
> attribute type mappings.
>
> regards
>
> David
>
>
> Von Welch wrote:
>> David,
>>> i) create the user's DN based on the name of its IDP, because we
>>> know
>>> that IDPs are already uniquely named by their DNS names.
>> It's much more than just the IdP name. To have two different CAs
>> generate the same DN for the same user, requires either:
>> 1) the IdP provide the DN, which I assert we are a long way from
>> being able to rely on.
>> 2) or the two CAs need to have complete agreement on the
>> attributes and algorithm to create the DN, the IdPs must all
>> generate the attributes, and both must have an equivalent policy
>> agreement with the IdP to receive those attributes. I argue this
>> is too many assumptions to be reasonable in practice. (This seems
>> to be trying to recreate the X.500 directory in the sky dream.)
>> Von
>> On Feb 9, 2007, at 11:06 AM, David Chadwick wrote:
>>> Hi Stephen
>>>
>>> It would be nice to tease out of your long DNs what the concept
>>> behind
>>> your generated DNs are.
>>>
>>> There is just one simple concept when creating globally unique
>>> hierarchical names (which is used by the DNS, X.500, URLs,
>>> filestores
>>> and even SPKI): create your own local name for a new child object
>>> that
>>> you create, and prefix it with your own globally unique name.
>>> I.e. every
>>> node in the naming tree (name space) is a naming authority for
>>> its child
>>> nodes. The root node of the tree, whose name is usually null (its
>>> a .
>>> for the DNS) is responsible for naming the first level nodes.
>>> There are
>>> usually internationally agreed or standardised procedures for this
>>> (which is where the DNS succeeded and X.500 failed). In the case
>>> of MS
>>> DOS filestores we have a letter of the alphabet to signify the disc
>>> volume. In the case of SPKI, its standardised procedure is that
>>> it uses
>>> a globally unique random ID for each first level node, which is
>>> created
>>> from the hash of the public key of the naming authority.
>>>
>>> I would be interested in the concept that underlies your naming
>>> scheme.
>>>
>>> What I am suggesting to Von, is that the naming concept and
>>> scheme that
>>> is adopted should be independent of the CA, and that each
>>> gridShib CA
>>> should conform to it.
>>>
>>> There would appear to be 2 sensible procedures that could be adopted
>>>
>>> i) create the user's DN based on the name of its IDP, because we
>>> know
>>> that IDPs are already uniquely named by their DNS names.
>>>
>>> ii) create the user's DN based on the name of the CA, since all
>>> CAs have
>>> to have unique names (otherwise the PKI is broken).
>>>
>>> regards
>>>
>>> David
>>>
>>> Stephen A. Langella wrote:
>>>> I agree with Alan, Dorian (the user CA for caBIG) provides a
>>>> similar
>>>> functionality allowing users to create grid credentials by
>>>> authenticating with it using their institution provided
>>>> credentials.
>>>> We have the same problem in that we must assign user's an
>>>> identity in
>>>> the grid space based of their identity in the local space. Our
>>>> experiences show that some in our community use eduPerson, while
>>>> others
>>>> do not. To be able to deal with the diversity of local
>>>> representations
>>>> of users that we encounter in our community we have defined the
>>>> notion
>>>> of attributes abstractly. For example Dorian only requires
>>>> that a
>>>> local identity provider be able to uniquely identify their
>>>> users, Dorian
>>>> does not place any restrictions on the attribute name
>>>> (eduPersonPrincipalName vs userId at XYZ). When a local Identity
>>>> Provider
>>>> is registered with Dorian, we specify to Dorian the name of the
>>>> attribute that the Identity Provider uses to uniquely identify its
>>>> users. When Dorian receives assertions from the Identity
>>>> Provider it
>>>> then uses the attribute name specified to extract the value.
>>>> Dorian
>>>> also assigns a unique id to each Identity Provider registered to
>>>> it.
>>>> Dorian assigns unique grid identities based on the Dorian CA
>>>> subject,
>>>> the id of the local Identity Provider, and the user's unique
>>>> identifier
>>>> within their IdP. For example:
>>>>
>>>> /O=OSU/OU=BMI/OU=caGrid/OU=Dorian/OU=cagrid05/OU=IdP
>>>> [1]/CN=someuser
>>>>
>>>> Of course in order to ensure the uniqueness of identities in a
>>>> Grid with
>>>> multiple Dorian's running or across Grids; appropriately
>>>> naming/namespacing CA(s) and enforcement of signing policies is of
>>>> critical importance. Just my two cents, comments welcome.
>>>>
>>>> --Steve
>>>>
>>>> Stephen Langella
>>>> Senior Research Specialist
>>>> Ohio State University
>>>> Department of Biomedical Informatics
>>>> Multiscale Computing Laboratory
>>>>
>>>> Office: (614) 292-9845
>>>> langella at bmi.osu.edu
>>>>
>>>> -----Original Message-----
>>>> From: ogsa-authn-bof-bounces at ogf.org
>>>> [mailto:ogsa-authn-bof-bounces at ogf.org] On Behalf Of Alan Sill
>>>> Sent: Wednesday, February 07, 2007 12:43 PM
>>>> To: Tom Scavo
>>>> Cc: OGSA Authentication WG BoF
>>>> Subject: Re: [ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
>>>>
>>>> I would agree that we have identified namespace mapping on the
>>>> front
>>>> end (persistent identifier to DN) as an issue that needs to be
>>>> addressed in a generalized AuthN approach if X.509 DN's are
>>>> required
>>>> for interoperability with existing grid software. Note this
>>>> issue is
>>>> similar to, but different from, the mapping needed on a resource or
>>>> service at the AuthZ level.
>>>>
>>>> Let me note that the use of eduPerson... in the discussion here is
>>>> interesting, but we need to come up with a standards architecture
>>>> that will be of use beyond just the educational space, e.g. for
>>>> interoperability with commercial grids, etc.
>>>>
>>>> All a very interesting discussion!
>>>>
>>>> On Feb 7, 2007, at 11:33 AM, Tom Scavo wrote:
>>>>
>>>>> Just a point of clarification with respect to the IdP...today
>>>>> campus
>>>>> IdPs are able to assert eduPersonPrincipalName (which has the same
>>>>> value across SPs), but many production IdPs are loathe to release
>>>>> ePPN. Instead, to prevent collusion among SPs (and to protect
>>>>> privacy), Internet2 is moving towards eduPersonTargetedID (ePTID).
>>>>> Unlike ePPN, the value of ePTID is specific to the SP, that is,
>>>>> ePTID
>>>>> is essentially a triple (see SAML2Core regarding the new
>>>>> persistent
>>>>> identifier). So by default, collusion is prevented.
>>>>>
>>>>> Moreover, I should point out that campus IdPs do not, and probably
>>>>> will not (unless the CA is integrated with the IdP), assert
>>>>> X509SubjectName. In the foreseeable future, t will be up to
>>>>> the Grid
>>>>> to map ePTID to DN. Today we algorithmically map a campus
>>>>> identifier
>>>>> to a DN. I think we will have to move to a persistent model
>>>>> regardless of the DN properties we choose to adopt. The model
>>>>> I have
>>>>> in mind is employed by myVocs today.
>>>>>
>>>>> Tom
>>>>>
>>>>> On 2/7/07, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>>>>> Hi Von
>>>>>>
>>>>>> to answer your specific points:
>>>>>>
>>>>>> Von Welch wrote:
>>>>>>> David,
>>>>>>>
>>>>>>> I should have phrased requirement #1 as:
>>>>>>>
>>>>>>>> 1) The same user, identified by a given IdP, using the same
>>>>>>>> GridShib-CA, MUST always map to the same DN in the Grid space
>>>>>>> In regards to dropping requirement #6, I think what you really
>>>>>>> want is
>>>>>>> to change requirement #1 so that it looks like the following:
>>>>>>>
>>>>>>> The same user, identified by a given IdP, using *any* GridShib-
>>>>>>> CA, MUST
>>>>>>> always map to the same DN.
>>>>>>>
>>>>>>> I have several concerns about this approach. I believe this
>>>>>>> means we
>>>>>>> have to do one of the following:
>>>>>>>
>>>>>>> 1) Every GridShib-CA instance must have access to the same user
>>>>>>> attributes and use the same transformation policy. This is tight
>>>>>>> coordination that I don't believe is possible to guarantee.
>>>>>> It is not unreasonable to assume that each IDP will have the same
>>>>>> privacy policy for the set of GridShib CAs that provide access
>>>>>> to the
>>>>>> same set of grid applications. Thus the user's attribute set
>>>>>> will be
>>>>>> identical in each instance. Therefore it is reasonable to
>>>>>> expect the
>>>>>> same DN to be issued by each of these CAs.
>>>>>>
>>>>>>
>>>>>>> 2) The IdP must provide the DN to all instances of the
>>>>>>> GridShib-CA.
>>>>>>> Again, global coordination that I don't see as possible.
>>>>>> I think it is reasonable to expect that if the IDP releases
>>>>>> the DN to
>>>>>> one of the CAs, it will release it to all of them. I dont see
>>>>>> why the
>>>>>> IDP would treat members of the set differently do you, since
>>>>>> the same
>>>>>> user is accessing the same grid applications in each case.
>>>>>>
>>>>>>
>>>>>>> I also find it disconcerting to have two different CAs issuing
>>>>>>> DNs in
>>>>>>> the same namespace in the event something goes wrong.
>>>>>> I dont find that disconcerting at all. The same user should be
>>>>>> entitled
>>>>>> to have the same DN regardless of the CA. I repeat that CA's
>>>>>> are not
>>>>>> naming authorities, they are certification authorities that
>>>>>> certify a
>>>>>> user's DN that is issued by a naming authority.
>>>>>>
>>>>>> (I agree we could
>>>>>>> move to a model of Issuer/DN for identity to resolve this.)
>>>>>> In this case the CA becomes a naming authority.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> Von
>>>>>>>
>>>>>>>
>>>>>>> On Feb 7, 2007, at 7:35 AM, David Chadwick wrote:
>>>>>>>
>>>>>>>> Hi Von
>>>>>>>>
>>>>>>>> It seems to me that requirements 1) and 6) conflict. I support
>>>>>>>> requirement 1) but not 6). If a user enters grid space via two
>>>>>>>> different Shibbolised portals, he will always be redirected
>>>>>>>> back to
>>>>>>>> his IDP to authenticate, and ought to get the same grid DN from
>>>>>>>> both
>>>>>>>> portals. Requirement 1) implies this. Requirement 6) states
>>>>>>>> this
>>>>>>>> will
>>>>>>>> not be the case. Hence I think you should drop requirement 6).
>>>>>>>>
>>>>>>>> regards
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>> Von Welch wrote:
>>>>>>>>> Nate,
>>>>>>>>> Here's my current thinking on this. Let me start with
>>>>>>>>> what I see
>>>>>>>>> as the requirements and then move on to what our plans are
>>>>>>>>> currently. Note that our current implementation (0.3.0) of
>>>>>>>>> the
>>>>>>>>> GridShib-CA does not implement this, but the plan is for
>>>>>>>>> the next
>>>>>>>>> version to do so.
>>>>>>>>> Requirements for a standard Grid profile follow. One could
>>>>>>>>> also
>>>>>>>>> imagine profiles that support psuedonymity, but I assert
>>>>>>>>> that the
>>>>>>>>> following profile is a standard mode of operation any Shib-
>>>>>>>>> >Grid
>>>>>>>>> translator SHOULD be able to support.
>>>>>>>>> 1) The same user, identified by a given IdP, MUST always
>>>>>>>>> map to
>>>>>>>>> the same DN in the Grid space
>>>>>>>>> 2) Two different users MUST never map to the same DN in the
>>>>>>>>> Grid space
>>>>>>>>> 3) Identifiers mapped from a given IdP MUST be mapped in
>>>>>>>>> such a
>>>>>>>>> manner that prevents conflict with identifiers mapped from
>>>>>>>>> another
>>>>>>>>> Idp. (Note that this implies that the same user, identified
>>>>>>>>> by two
>>>>>>>>> different IdPs, will have two different DNs.)
>>>>>>>>> 4) It SHOULD be discernible from a DN, which IdP asserted
>>>>>>>>> the
>>>>>>>>> mapped identifier.
>>>>>>>>> 5) DNs SHOULD contain a reasonable facsimile of the
>>>>>>>>> user's legal
>>>>>>>>> name. (This motivation for this comes from the IGTF.)
>>>>>>>>> 6) DNs created by two different instances of a GridShib-CA
>>>>>>>>> SHOULD
>>>>>>>>> be done in such a manner as to prevent any conflict. This
>>>>>>>>> implies
>>>>>>>>> the same user, from the same IdP going through two different
>>>>>>>>> GridShib-CA instances will get two different DNs. The only
>>>>>>>>> exception
>>>>>>>>> to this should be if both GridShib-CA instances are operated
>>>>>>>>> by the
>>>>>>>>> same organization in some sort of replication scenario
>>>>>>>>> (the are
>>>>>>>>> logically the same instance).
>>>>>>>>> Currently Shibboleth identifiers are scoped to the issuing
>>>>>>>>> IdP.
>>>>>>>>> This
>>>>>>>>> makes some of the requirements above easier to meet. If this
>>>>>>>>> changes, it will require the addition of a IdP identifier to
>>>>>>>>> the DN
>>>>>>>>> given below. See the following URL for a discussion of this:
>>>>>>>>> http://
>>>>>>>>> bugzilla.globus.org/bugzilla/show_bug.cgi?id=4888
>>>>>>>>> Our plan is for the GridShib-CA to issue DNs which look
>>>>>>>>> like the
>>>>>>>>> following:
>>>>>>>>> /DC=edu/DC=uiuc/DC=ncsa/DC=gridshib-ca/O=User Certificate/
>>>>>>>>> CN=<ePTID>/
>>>>>>>>> <displayName>
>>>>>>>>> The DC components serve to uniquely identify the GridShib-CA
>>>>>>>>> instance in question and meet requirement #6.
>>>>>>>>> Where <ePTID> is the eduPerson Targeted ID and
>>>>>>>>> <displayName> is
>>>>>>>>> the
>>>>>>>>> displayName attribute, both as provided by the IdP.
>>>>>>>>> ePTID is used because it has a persistence quality lacked
>>>>>>>>> by ePPN
>>>>>>>>> (i.e. it is guaranteed never to be reassigned). This serves to
>>>>>>>>> meet
>>>>>>>>> requirements #1-#4.
>>>>>>>>> displayName provides the facsimile of the user's legal name
>>>>>>>>> (requirement #5).
>>>>>>>>> That said, we expect some institutions may have problems
>>>>>>>>> providing
>>>>>>>>> ePTID, so we expect to be able to fall back to ePPN,
>>>>>>>>> recognizing
>>>>>>>>> that doesn't guarantee meeting requirement #2 as ePPN
>>>>>>>>> could, in
>>>>>>>>> theory be re-assigned, and doesn't meet requirement #5 as
>>>>>>>>> ePPN
>>>>>>>>> looks
>>>>>>>>> more like an email address than a legal name.
>>>>>>>>> Comments welcome.
>>>>>>>>> Von
>>>>>>>>> On Feb 5, 2007, at 10:26 PM, Nate Klingenstein wrote:
>>>>>>>>>> OGSA-Authn BoFfers,
>>>>>>>>>>
>>>>>>>>>> At our meeting in North Carolina, I flagged the
>>>>>>>>>> translation of
>>>>>>>>>> names
>>>>>>>>>> from the grid world to the institutional world and vice
>>>>>>>>>> versa as
>>>>>>>>>> being an important topic for discussion in the next several
>>>>>>>>>> months.
>>>>>>>>>> We need to begin to document current practices so that a path
>>>>>>>>>> towards
>>>>>>>>>> convergence can be identified.
>>>>>>>>>>
>>>>>>>>>> I'd like to give a brief background for those on the list who
>>>>>>>>>> aren't
>>>>>>>>>> heavily steeped in this problem. The various Shibboleth-grid
>>>>>>>>>> integration projects out there all want to bootstrap grid
>>>>>>>>>> authentication (and sometimes authorization) by use of
>>>>>>>>>> institutional
>>>>>>>>>> authentication. This authentication generally results in a
>>>>>>>>>> unique
>>>>>>>>>> identifier for the user which differs in form from that used
>>>>>>>>>> on the
>>>>>>>>>> grid, and potentially in semantic meaning as well.
>>>>>>>>>>
>>>>>>>>>> There is a lot of different types of identifiers. If a
>>>>>>>>>> campus is
>>>>>>>>>> using LDAP, the user will also have a DN associated with
>>>>>>>>>> their
>>>>>>>>>> entry,
>>>>>>>>>> but this directory DN is rarely used as an identifier in
>>>>>>>>>> practice and
>>>>>>>>>> usually won't correspond to those issued in x.509
>>>>>>>>>> certificates
>>>>>>>>>> anyway. Local practices for primary identifier vary based on
>>>>>>>>>> local
>>>>>>>>>> needs, and many institutions don't use LDAP at all.
>>>>>>>>>> eduPersonPrincipalName, which takes the form of
>>>>>>>>>> name at domain, has
>>>>>>>>>> proven the most ubiquitous and successful in inter-realm
>>>>>>>>>> deployment
>>>>>>>>>> thus far.
>>>>>>>>>>
>>>>>>>>>> The critical step is translation of the identifier that
>>>>>>>>>> results from
>>>>>>>>>> campus authentication to a grid-usable credential(and,
>>>>>>>>>> potentially,
>>>>>>>>>> vice-versa for callbacks). This bootstrap can be
>>>>>>>>>> performed in
>>>>>>>>>> many
>>>>>>>>>> ways at many different points. Differences in practice could
>>>>>>>>>> lead to
>>>>>>>>>> non-interoperability and general confusion for grid SP's and
>>>>>>>>>> campus
>>>>>>>>>> IdP's alike.
>>>>>>>>>>
>>>>>>>>>> There are several projects out there that have bridged this
>>>>>>>>>> gap in
>>>>>>>>>> creative ways, such as SHEBANGS, SLCS, and GridShib. I'd
>>>>>>>>>> like to
>>>>>>>>>> invite each project to take some time within the next
>>>>>>>>>> month to
>>>>>>>>>> describe in a brief document how they linked Shibboleth
>>>>>>>>>> authentication to the grid as a first step. If there's a
>>>>>>>>>> willingness
>>>>>>>>>> to document additional passing of authorization or attribute
>>>>>>>>>> information, I think that would be useful as well.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Nate.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> ogsa-authn-bof mailing list
>>>>>>>>>> ogsa-authn-bof at ogf.org
>>>>>>>>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ogsa-authn-bof mailing list
>>>>>>>>> ogsa-authn-bof at ogf.org
>>>>>>>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>>>>>> --
>>>>>>>> ***************************************************************
>>>>>>>> **
>>>>>>>> David W. Chadwick, BSc PhD
>>>>>>>> Professor of Information Systems Security
>>>>>>>> The Computing Laboratory, University of Kent, Canterbury,
>>>>>>>> CT2 7NF
>>>>>>>> Skype Name: davidwchadwick
>>>>>>>> Tel: +44 1227 82 3221
>>>>>>>> Fax +44 1227 762 811
>>>>>>>> Mobile: +44 77 96 44 7184
>>>>>>>> Email: D.W.Chadwick at kent.ac.uk
>>>>>>>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/
>>>>>>>> index.html
>>>>>>>> Research Web site: http://sec.cs.kent.ac.uk
>>>>>>>> Entrust key validation string: MLJ9-DU5T-HV8J
>>>>>>>> PGP Key ID is 0xBC238DE5
>>>>>>>>
>>>>>>>> ***************************************************************
>>>>>>>> **
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>> *****************************************************************
>>>>>> David W. Chadwick, BSc PhD
>>>>>> Professor of Information Systems Security
>>>>>> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>>>>>> Skype Name: davidwchadwick
>>>>>> Tel: +44 1227 82 3221
>>>>>> Fax +44 1227 762 811
>>>>>> Mobile: +44 77 96 44 7184
>>>>>> Email: D.W.Chadwick at kent.ac.uk
>>>>>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>>>>>> Research Web site: http://sec.cs.kent.ac.uk
>>>>>> Entrust key validation string: MLJ9-DU5T-HV8J
>>>>>> PGP Key ID is 0xBC238DE5
>>>>>>
>>>>>> *****************************************************************
>>>>>> _______________________________________________
>>>>>> ogsa-authn-bof mailing list
>>>>>> ogsa-authn-bof at ogf.org
>>>>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>>>>
>>>>> _______________________________________________
>>>>> ogsa-authn-bof mailing list
>>>>> ogsa-authn-bof at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>>
>>>> Alan Sill, Ph.D
>>>> TIGRE Senior Scientist, High Performance Computing Center
>>>> Adjunct Professor of Physics
>>>> TTU
>>>>
>>>> ===================================================================
>>>> =
>>>> : Alan Sill, Texas Tech University Office: Admin 233, MS
>>>> 4-1167 :
>>>> : e-mail: Alan.Sill at ttu.edu ph. 806-742-4350 fax
>>>> 806-742-4358 :
>>>> ===================================================================
>>>> =
>>>>
>>>>
>>>> _______________________________________________
>>>> ogsa-authn-bof mailing list
>>>> ogsa-authn-bof at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>> _______________________________________________
>>>> ogsa-authn-bof mailing list
>>>> ogsa-authn-bof at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>>
>>>
>>> --
>>> *****************************************************************
>>> David W. Chadwick, BSc PhD
>>> Professor of Information Systems Security
>>> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>>> Skype Name: davidwchadwick
>>> Tel: +44 1227 82 3221
>>> Fax +44 1227 762 811
>>> Mobile: +44 77 96 44 7184
>>> Email: D.W.Chadwick at kent.ac.uk
>>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>>> Research Web site: http://sec.cs.kent.ac.uk
>>> Entrust key validation string: MLJ9-DU5T-HV8J
>>> PGP Key ID is 0xBC238DE5
>>>
>>> *****************************************************************
>>>
>>> _______________________________________________
>>> ogsa-authn-bof mailing list
>>> ogsa-authn-bof at ogf.org
>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>
>
> --
>
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/
> index.html
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************
>
More information about the ogsa-authn-bof
mailing list