El 22/05/14 15:19, Rhys Smith escribió:
> On 22 May 2014, at 13:39, Rhys Smith <[log in to unmask]> wrote:
>
>>> moonshot-id-targeted-to-realm (similar to CUI)
>>> moonshot-id-targeted-to-rp (similar to the targeted ID in SAML)
>>> moonshot-id-targeted-to-coi (similar to the targeted ID in SAML, but using COI instead of RP)
>> I can definitely see the utility of two targeted-to-gss-acceptor-realm (as discussed previously) and targeted-to-coo.
>
>
> So I think we’re looking at something like the following (not necessarily suggesting these names by the way! - and assuming we went with the value@scope representation, subject to further discussion):
>
> 1) moonshot-tr-realm-targetedid
>
> Value a SHA256 (?) hash of Gss-Acceptor-Realm, username, salt. Represented as value@idp-realm
>
> 2) moonshot-tr-coi-targetedid
>
> Value a SHA 256 (?) hash of CoI-Identifier, username, salt. Represented as [log in to unmask]
>
> And of course the existing User-Name attribute, if present.
>
>
> So then services would look for:
> 1) User-Name; if not present look at
> 2) moonshot-tr-coi-targetedid; if not present look at
> 3) moonshot-tr-realm-targetedid; if not present then
> 4) user is anonymous (identifier-less).
Making use of 1), 3) or 4) can gives the service this kind of CUI-like
attribute we are looking for, but I still see CoI like a more generic
authorization information, something like group, role, entitlement, etc,
etc..... and I would expect this in something like the SAML sentence.
Best regards, Gabi.
>
> ?
>
> Rhys.
> --
> Dr Rhys Smith
> Identity, Access, and Middleware Specialist
> Cardiff University & Janet, the UK's research and education network
>
> email: [log in to unmask] / [log in to unmask]
> GPG: 0x4638C985
>
--
--------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [log in to unmask]
|