intent to define

[cappelaere]

within Work:

Role and Permissions

Permission exchange is extremely critical for the tailoring of data
access to a specific individual. Permissions could be pre-negotiated
across organizations.

Issue is that user should not be able to modify this field (and many
others such as organization, email, job, role...) to be accepted by
another party.

An alternative is to provide a non-modifiable/verifiable PKI
certificate.

[mark...@gmail.com]

On May 2, 7:29 am, cappelaere <cappela...@gmail.com> wrote:
> within Work:
>
> Role and Permissions
>
> Permission exchange is extremely critical for the tailoring of data
> access to a specific individual. Permissions could be pre-negotiated
> across organizations.

What would be the syntax of permissions attribute? Would there be
one for each format, e.g., an XACML permissions?

Mark Wahl
Informed Control Inc.

[cappelaere]

in my mind, static permissions could simply be pre-agreed upon tokens
or strings. If your permission set contains that string, the
reciprocating entity would grant you access to a specific resource.
Each user would have a permission set (not editable by the user and
granted by his/her organization) that could contain comma delimited
strings.
Organizations would agree to grant those permissions to specific
users.
Trust relationships between organizations would allow access to
external users (via OpenId authentication) to resources.
Storing a given PKI certificate that may contain those attributes
might also be an option. The key is to make sure that the user does
not modify those granted attributes. User would still allow access to
the PKI or not.
Pat.

On May 8, 1:38 pm, "mark.w...@informed-control.com"