[PORTLETSPEC3-29] P3PUserInfos may need clarification and could be outdated in some areas Created: 28/May/13  Updated: 22/Jan/16  Resolved: 22/Jan/16

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: clarification, identity, privacy

 Description   

First of all there seems to be an issue and missing documentation of the PortletRequest.P3PUserInfos enum.

Aside from similar observations for containers like Liferay this was discussed and answered for WebSphere Portal in late 2008
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014161216

IBM support engineer Jim Barnes replied:
>I talked with dev on this and it seems this is a errata in the spec and the toString must be called, and this will be pushed in the next >errata for the spec
>
>Jim

Specifying and documenting this properly is the minimum requirement I'd see we should cover in this JSR.

Beside I'd like to raise the question, to what extent the enum attributes are still relevant.
Fields like: USER_HOMEINFO_TELECOM_PAGER_NUMBER
while other obvious ones like
USER_HOMEINFO_ONLINE_TWITTER (or _FACEBOOK, etc.) are clearly missing in today's world.

The EG of JSR-351, Identity Management for Java discussed similar challenges, including the problem of enums and their limited extensibility as well as an often changing set of Identity Attributes that this enum and the Portlet 2.0 spec hoped to cover somehow.
I may propose synergies with JSR-351 in the "extensions" component, but wanted to mention it here, too. Potentially an area where 351 could help, but at the very least the enum vs. toString() problem should be resolved and the enum better documented. Where appropriate some attributes may be added others at least deprecated.



 Comments   
Comment by andre.hagemeier [ 31/Jul/13 ]

I wonder whether adding more fields would be the right way to go. From my point of view, custom data is retrieved by other means. I assume vendors provide APIs to access user data, like WebSPhere Portal does with PUMA. These APIs would be more powerful and flexible then any enum retrieved from the portlet request could ever be.
In the portlet4.0 spec, people might wonder, why we added twitter and facebook, because other they ceased to exist. I think, if any, the most important user features should be part of the enum (given name, last name, email, phone, birthday, etc) and the rest should be deprecated.

Comment by msnicklous [ 30/Aug/13 ]

I think we should keep this one open for now and discuss this issue when we talk about device support.

Comment by msnicklous [ 22/Jan/16 ]

As of this time, there won't be further work on the P3PUserInfos, as that spec seems to be dead.





[OPENPTK-283] Implement SCIM 1.0 server interface Created: 27/Jul/11  Updated: 05/Apr/12

Status: Open
Project: openptk
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: Scott Fehrman Assignee: Scott Fehrman
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on OPENPTK-299 Overload HTTP POST to support other H... Open
depends on OPENPTK-142 Add REST aliases for configuration de... In Progress
depends on OPENPTK-321 Server (REST) Tier external Attribute... In Progress
depends on OPENPTK-300 Support data type declaration via URI Closed
Tags: cloud, identity, scim

 Description   

Evaluate the Simple Cloud Identity Management (SCIM) specification, APIs an schemas. Determine the feasibility and level-of-effort to implement the "server side" (receive, process, reply to SCIM RESTful HTTP Requests), this could be an enhancement to the OpenPTK Server. Determine the feasibility and level-of-effort to implement the "client side" (format,submit SCIM RESTful HTTP Requests), this could be an enhancement to the OpenPTK Client-side libraries and utilities.

reference = http://www.simplecloud.info



 Comments   
Comment by Scott Fehrman [ 24/Sep/11 ]

Two Project pages have been created on the documentation site: http://docs.openptk.org

http://docs.openptk.org/design/service-scim Capture requirements and the design process related to creating a SCIM compliant OpenPTK Service
http://docs.openptk.org/design/server-scim-provider Capture requirements and the design of a Server-Tier Provider implementation that supports the SCIM specification
Comment by Scott Fehrman [ 30/Nov/11 ]

The SCIM spec uses / requires these features

Comment by Scott Fehrman [ 29/Jan/12 ]

This will provide the attribute mapping mechanism for the SCIM 1.0 scheme

Comment by Scott Fehrman [ 24/Mar/12 ]

This issue will focus on the Server interface that will be designed to receive SCIM 1.0 requests.

Project web page: http://docs.openptk.org/projects/server-scim-provider





Generated at Sat Apr 29 15:34:48 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.