KMLM List

[<james.wismer@xxxxxxxxxxxxxxxxxx>]

My understanding is that the requestor ID and the customer ID are
provided to the client by the vendor.  They are vendor specific.  Some
vendors may choose to implement IP authentication to authenticate the
service call itself.  Additionally, they may choose to use the IDs in
the request to authorize the clients access to the specific customer's
report.

 

The SUSHI spec does not specify the exact authentication model to use.
It is left up to the vendor.  According to the spec, "Service Providers
can limit access to only known Requestor IDs or even known Requestor IDs
that a customer has approved".

 

Thanks.

Jim Wismer

Thomson Reuters

 

 

From: Kim, Tae [mailto:Tae.Kim@xxxxxxxxxxxxxxxxxxxx] ;
Sent: Friday, April 17, 2009 12:59 PM
To: Arndt, Dave (LNG-DAY); sushidevelopers@xxxxxxxxxxxxx
Subject: Re: [sushidevelopers] COUNTER XML - three questions

 

This makes it difficult for clients to connect to different services.

Ideally, there should only be one authentication mechanism at least in
the soap package itself.
(I'm not saying the current implementation is perfect but anything as
long as there's only one)
Custom code for every service defeats the purpose of standards and
interoperability.
Already, I'm having to implement WS-Security for Proquest.
Since WS-Security has multiple tokens such as clear-text password,
password digest, binary security tokens, SAML, etc. , etc.,
I really see a pandora's box for inhibiting and complicating SUSHI
interoperability. 

Multiple authentication schemes have always created headaches in the
past.
Look at Athens, Shibboleth, IP Authentication, etc. etc.

-Tae Kim

On 4/17/09 9:44 AM, "Arndt, Dave (LNG-DAY)" <dave.arndt@xxxxxxxxxxxx>
wrote:

More of a SOAPBox comment  :-)

I think many folks will continue to have confusion around the
authentication and name/address/email type information that is put in
the "working" part of the SUSHI payload.  Are they to be used for
service or end user authentication?  If so which parts?

I believe part of the information in the Requestor and Customer
Reference sections are intended to be used for authentication but don't
provide the SUSHI provider with enough information to do the actual
authentication due to the fact that each SUSHI provider may need
different authentication information and furthermore each client might
want different types of authentication supported for a single SUSHI
provider.  Think about all the different types of authentication there
is out there right now.

In my opinion the information in the requestor and customer reference
sections of the request should be purely informational and SUSHI should
defer the implementation of both service authentication and end user
authentication to the SUSHI provider.

I have almost the similar views on platform.

Thanks,
Dave Arndt - Elsevier Services Architect
937-865-6800 x56221 
Web Services, Customer System, Reporting and DW
www.sciencedirect.com  www.scopus.com

"The significant problems we have cannot be solved at the same level of
thinking with which we created them."   Albert Einstein
-----Original Message-----
From: Colin Prince [mailto:colin.prince@xxxxxxxxxxx]
Sent: Friday, April 17, 2009 10:17 AM
To: sushidevelopers@xxxxxxxxxxxxx
Subject: [sushidevelopers] COUNTER XML - three questions

Hello Everyone,

I'm putting together a COUNTER XML report and referencing the schema
here: http://www.niso.org/schemas/sushi/counter3_0.xsd

Attached is my first attempt, report.xml. I'd be grateful for any
comments.

It's not clear to me what I could put in the ItemPlatform element.

From the docs:

"The platform is the name of the online host as determined by the
service provider, e.g.,  EBSCOhost, ScienceDirect, etc."

We host journals at the University of Toronto Libraries using OJS
software. There are many different publishers.

Perhaps "University of Toronto Libraries" is the platform, or is it
"OJS" maybe?

Two more questions regarding XML details:

Should the ItemPerformance instances be symmetrical, that is, if I put
ft_html in one ItemPerformance instance, do I have to make sure it is in
all of them?

If we do not have a particular piece of data, is it preferable to skip
the element, put an empty element, or put an element containing the
integer zero?

Thanks,
Colin

--
Colin Prince
416-978-7636
Scholarly Communication Initiatives
University of Toronto Libraries