Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 36 Next »

UMA1 Interop Participants and Solutions

Main UMA1 Interop Testing page Features and Feature Tests | Results | uma-dev list

Participants in UMA1 testing must register on this page, either by editing the page or by contacting the UMA WG chair, and should subscribe to the uma-dev mailing list, which will be used for interop-related communications. No ranking of other special meaning should be attached to the order in which participants appear. Participants must fill out their relevant rows in the following tables:

Participant information

Participant name and logoContact names/emailsSolution full nameSolution abbrevRoles (AS, RS, C)
Gluu (logo, handle)
Mike Schwartz: mike-at-gluu.org
Yuriy Zabrovarnayy: yuriy-at-gluu.org
OXAuthOXAS, RS, C?
Apache plugin?APRS?
Cloud Identity Limited, (logo, handle)Maciej Machulak: maciej.machulak(AT)cloudidentity.co.ukNuveAMCIAS, RS, C
  Python/Java UMAPURS, C
Roland HedbergRoland Hedberg: roland.hedberg-at-adm.umu.sePyUMARHAS, RS, C

Solution information: AS role

Solution:roleConfig data URLSupports dynamic client registration for RS and C?Other details
OX:AShttps://seed.gluu.org/.well-known/uma-configurationRS: yes, C: yes

See:

CI:AShttps://demo.nuveam.com/.well-known/uma-configurationRS: yes, C: yes

Product Website, Online Demo

RH:AS   

Solution information: RS role

Any RS participating in interop has to expose either multiple resource sets (as registered with the AS) or multiple scopes, or both. This enables testing UMA-specific interop around sufficient/insufficient authz data, permission tickets that match/don't match the requested type of access, etc., while not dictating the specifics of what the API looks like. Each RS participant needs to provide enough information directly in the table below to explain how to access these differential resource sets and scopes, e.g. the URLs, parameters, etc. This way, clients can tell whether the RS was at fault or not if something goes wrong with authorization. It is RECOMMENDED that each RS document exactly the one or two endpoints/calls/parameters that are sufficient for UMA interop testing purposes, to limit the universe of potential actions that a client can take.

Solution:roleAPI infoSDK avail?Login URL and RO credsProtected resource URL(s) infoClient SDK/library infoExpects dynamic client registration at AS?Other details
OX:RSJavaWill fill in when RS is up    
CI:RShttps://nuvepds.appspot.com/about/apiPython and Javahttps://nuvepds.appspot.com (Sign in with your social profile)https://nuvepds.appspot.com/about/api Optional 
RH:RSUses "pbryan" (http-json-resource) https://xenosmilus.umdc.umu.se:8777/login.html (user:alice, password:krall)Base URL for alice's resources: https://xenosmilus.umdc.umu.se:8777/json/aliceAvailable in Python and Java (sample at https://nuvepdsclient.appspot.com/) – where? Supports webfinger. Supports acct and http identifier urls.

Solution information: C role

Solution:roleApp typeOther details
OX:CWill fill in when C is up 
CI:Chttps://nuvepdsclient.appspot.com/Sign in using social profile
RH:C  
  • No labels