To add a 13th option,
How about IdentityStore? That would reflect that we are storing identity
attributes.
On 3/23/15 5:15 PM, Rudy De Busscher wrote:
> Hi,
>
> /the concept of "the store where users/callers and optionally the
> group/role data resides"./
>
>
> Since you also have the group/role information, it is _not only
> _Authentication info anymore. So *Authentication Store* is then
> confusing.
>
> Store is indeed too general, so what about *security provider* (if I
> have to take a term from the list proposed here)?
>
> regards
> Rudy
>
> On 23 March 2015 at 22:03, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> On Monday, March 23, 2015, Alex Kosowski <alex.kosowski_at_oracle.com
> <mailto:alex.kosowski_at_oracle.com>> wrote:
>
> Hi Arjan,
>
>> Does this indicates your preference, or is it just the term
>> Shiro happened to use?
> It was just a starting point.
>
>
> Okay ;)
>
>
>
>
>> David Blevins: Store
>> Arjan Tijms: Authentication Store
>>
> Authentication Store is fine with me. Store seems a little
> broad, but less typing.
>
>
> Yes, for me too just store would feel too broad. AuthStore would
> seem to work at first, but I agree with Les who stated in another
> thread that we shouldn't use just "auth" anywhere.
>
> While very common, it unfortunately makes it hard to distinguish
> between authentication and authorization.
>
> So we now have;
>
> David Blevins: Store
> Arjan Tijms: Authentication Store
> Alex Kosowski; Authentication Store
>
> Anyone else?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> Thanks,
> Alex
>
> On 3/20/15 8:56 AM, arjan tijms wrote:
>> Hi,
>>
>> The doc is a great start, thanks Alex :)
>>
>> I noticed that relevant to the issue described in this
>> thread, the document has chosen the term "Realm" for the
>> concept of "the store where users/callers and optionally the
>> group/role data resides".
>>
>> Does this indicates your preference, or is it just the term
>> Shiro happened to use?
>>
>> What about a round of voting (non-binding at this stage, just
>> to test the waters)? That way we at least can establish a
>> working term that we can use in the different discussions and
>> issues that have already all started to use different terms.
>>
>> The list of proposed terms is now the following:
>>
>> 1. security provider (WebLogic)
>> 2. realm (Tomcat, Shiro, some hints in Servlet spec)
>> 3. (authentication) repository
>> 4. (authentication) store
>> 5. login module (JAAS)
>> 6. identity manager (Undertow)
>> 7. service provider
>> 8. relying party
>> 9. authenticator (Resin, OmniSecurity, Seam Security)
>> 10. user service (?, used by 375 JSR)
>> 11. authentication provider (Spring Security)
>> 12. identity provider
>>
>> I'd like to ask everyone on this list to vote for your
>> preferred term. David had already expressed favoring "store"
>> in the JIRA issue, which is together with "repository" also
>> my favorite, although I like to prefix it with "authentication".
>>
>> So the current outcome is:
>>
>> David Blevins: Store
>> Arjan Tijms: Authentication Store
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 19, 2015 at 3:25 AM, Alex Kosowski
>> <alex.kosowski_at_oracle.com> wrote:
>>
>> Hi,
>>
>> I created a draft document for adding/editing EE Security
>> API Terminology on an on-going basis.
>>
>> https://docs.google.com/document/d/1eaNCUa78Eytt73WYvDHrsS3klTzHL0xD5vswHhT-KVY/edit?usp=sharing
>>
>> This a Google doc viewable by the public and editable by
>> those in the Google Group
>> jsr375-experts_at_googlegroups.com, of which all of you
>> should be a member. <http://jsr375-experts@googlegroups.com,>
>>
>> Alex
>>
>>
>> On 3/8/15 5:01 PM, arjan tijms wrote:
>>> Hi there,
>>>
>>> A while ago I created
>>> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-1, which seeks to
>>> establish clear terminology for two concepts that often come up in
>>> authentication:
>>>
>>> 1. The (user) interaction method via which credentials are obtained
>>> (FORM, BASIC, etc)
>>> 2. The store where users/callers and optionally the group/role data resides
>>>
>>> Not only do I see very different terms being used for both of these
>>> concepts which is a problem by itself, but the lack of consistent
>>> terminology makes it unclear what people are really asking at times.
>>>
>>> Your thoughts?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>
>>
>
>
>
>
>